Move the .gitrepo config file to .gitrepo/config

Changes

@@ -2,6 +2,7 @@
 version: 0.4.0
 date:    Thu Nov  8 12:26:38 CET 2018
 changes:
+- Moved .gitrepo to .gitrepo/config
 - Fix #325 Do not squash main repo commits
 - Improve error message for worktree handling
 - Make version checking portable. #307
@@ -35,6 +36,11 @@ changes:
 - Fix env var bug in test/push.t
 - Do not overwrite author information
 ---
+version: 0.4.0
+date:    Tue Oct  25 23:08:56 PST 2018
+changes:
+- Move .gitrepo to .gitrepo/config
+---
 version: 0.3.1
 date:    Tue Jan  3 23:08:56 PST 2017
 changes:

Intro.pod

@@ -260,7 +260,7 @@ Consider the equivalent subrepo commands:
     $ git subrepo pull foo
     $ git subrepo push foo
 
-Collaborators see a file called 'foo/.gitrepo', and know that the subdir is a
+Collaborators see a file called 'foo/.gitrepo/config', and know that the subdir is a
 subrepo. The file contains all the information needed by future commands
 applied to that subrepo.
 
@@ -348,7 +348,7 @@ Given this we do the following steps internally:
 
 =item * Create a new subrepo commit object for the subdir content
 
-=item * Add a state file called .gitrepo to the new subrepo/subdir
+=item * Add a state file called .gitrepo/config to the new subrepo/subdir
 
 =item * Amend the merge commit with this new file
 
@@ -365,7 +365,7 @@ as possible. You don't need to have the subrepo history in your main
 project, since it is immutably available elsewhere, and you have a pointer
 to that place.
 
-The new foo/.gitrepo file looks like this:
+The new foo/.gitrepo/config file looks like this:
 
     [subrepo]
             remote = [email protected]:you/foo.git
@@ -382,7 +382,7 @@ collaborators need this url to pull/push in the future.
 
 The next command is the pull command. Normally you just give it the subrepo's
 subdir path (although you can change the branch with -b), and it will get the
-other info from the subdir/.gitrepo file.
+other info from the subdir/.gitrepo/config file.
 
 The pull command does these steps:
 
@@ -398,7 +398,7 @@ The pull command does these steps:
 
 =item * Commit the HEAD of the rebased content
 
-=item * Update/amend the .gitrepo file
+=item * Update/amend the .gitrepo/config file
 
 =back
 

ReadMe.pod

@@ -70,9 +70,9 @@ The C<git-subrepo> command benefits these roles in the following ways:
 
 =item * Collaborators do not need to install unless they want to push/pull.
 
-=item * Collaborators know when a subdir is a subrepo (it has a C<.gitrepo> file).
+=item * Collaborators know when a subdir is a subrepo (it has a C<.gitrepo/config> file).
 
-=item * The C<.gitrepo> file never gets pushed back to the subrepo upstream.
+=item * The C<.gitrepo/config> file never gets pushed back to the subrepo upstream.
 
 =item * Well named branches and remotes are generated for manual operations.
 
@@ -141,7 +141,7 @@ and merged into the subdir.
 
 The subrepo history is I<squashed> into a single commit that contains the
 reference information. This information is also stored in a special file
-called C<< <subdir>/.gitrepo >>. The presence of this file indicates that the
+called C<< <subdir>/.gitrepo/config >>. The presence of this file indicates that the
 directory is a subrepo.
 
 All subsequent commands refer to the subrepo by the name of the
@@ -164,14 +164,14 @@ If you want to expose a subdirectory of your project as a published subrepo,
 this command will do that. It will split out the content of a normal
 subdirectory into a branch and start tracking it as a subrepo. Afterwards your
 original repo will look exactly the same except that there will be a C<<
-<subdir>/.gitrepo >> file.
+<subdir>/.gitrepo/config >> file.
 
 If you specify the C<--remote> (and optionally the C<--branch>) option, the
-values will be added to the C<< <subdir>/.gitrepo >> file. The C<--remote>
+values will be added to the C<< <subdir>/.gitrepo/config >> file. The C<--remote>
 option is the upstream URL, and the C<--branch> option is the upstream branch
 to push to. These values will be needed to do a C<git subrepo push> command,
 but they can be provided later on the C<push> command (and saved to C<<
-<subdir>/.gitrepo >> if you also specify the C<--update> option).
+<subdir>/.gitrepo/config >> if you also specify the C<--update> option).
 
 Note: You will need to create the empty upstream repo and push to it on your
       own, using C<< git subrepo push <subdir> >>.
@@ -186,11 +186,11 @@ The C<init> command accepts the C<--branch=> and C<--remote=> options.
 Update the subrepo subdir with the latest upstream changes.
 
 The C<pull> command fetches the latest content from the remote branch pointed
-to by the subrepo's C<.gitrepo> file, and then tries to merge the changes into
+to by the subrepo's C<.gitrepo/config> file, and then tries to merge the changes into
 the corresponding subdir. It does this by making a branch of the local commits
 to the subdir and then merging or rebasing (see below) it with the fetched
 upstream content. After the merge, the content of the new branch replaces your
-subdir, the C<.gitrepo> file is updated and a single 'pull' commit is added to
+subdir, the C<.gitrepo/config> file is updated and a single 'pull' commit is added to
 your mainline history.
 
 The C<pull> command will attempt to do the following commands in one go:
@@ -339,9 +339,9 @@ The C<clean> command accepts the C<--all>, C<--ALL>, and C<--force> options.
 
 =item C<< git subrepo config <subdir> <option> [<value>] [-f] >>
 
-Read or update configuration values in the subdir/.gitrepo file.
+Read or update configuration values in the subdir/.gitrepo/config file.
 
-Because most of the values stored in the .gitrepo file are generated you
+Because most of the values stored in the .gitrepo/config file are generated you
 will need to use C<--force> if you want to change anything else then the
 C<method> option.
 
@@ -408,7 +408,7 @@ commands that C<--all> works for.
 =item C<< --branch=<branch-name> >> (C<< -b <branch-name> >>)
 
 Use a different upstream branch-name than the remote HEAD or the one saved in
-C<.gitrepo> locally.
+C<.gitrepo/config> locally.
 
 =item C<--dry-run> (C<-N>)
 
@@ -446,7 +446,7 @@ setup for push).
 
 =item C<< --remote=<remote-url> >> (C<< -r <remote-url> >>)
 
-Use a different remote-url than the one saved in C<.gitrepo> locally.
+Use a different remote-url than the one saved in C<.gitrepo/config> locally.
 
 =item C<--squash> (C<-s>)
 
@@ -455,7 +455,7 @@ Squash all commits on a push into one new commit.
 =item C<--update> (C<-u>)
 
 If C<--branch> or C<--remote> are used, and the command updates the
-C<.gitrepo> file, include these values to the update.
+C<.gitrepo/config> file, include these values to the update.
 
 =back
 
@@ -679,7 +679,7 @@ C<irc.freenode.net>.
 
 =item * Written in (very modern) Bash, with full test suite. Take a look.
 
-=item * A C<.gitrepo> file never is in the top level dir (next to a C<.git/> dir).
+=item * A C<.gitrepo/config> file never is in the top level dir (next to a C<.git/> dir).
 
 =back
 

doc/git-subrepo.swim

@@ -50,8 +50,8 @@ The `git-subrepo` command benefits these roles in the following ways:
 * Users get your repo and all your subrepos just by cloning your repo.
 * Users do not need to install `git-subrepo`, ever.
 * Collaborators do not need to install unless they want to push/pull.
-* Collaborators know when a subdir is a subrepo (it has a `.gitrepo` file).
-* The `.gitrepo` file never gets pushed back to the subrepo upstream.
+* Collaborators know when a subdir is a subrepo (it has a `.gitrepo/config` file).
+* The `.gitrepo/config` file never gets pushed back to the subrepo upstream.
 * Well named branches and remotes are generated for manual operations.
 * Owners do not deal with the complications of keeping submodules in sync.
 * Subrepo repositories can contain subrepos themselves.
@@ -100,7 +100,7 @@ the same arguments. Keep reading…
 
   The subrepo history is /squashed/ into a single commit that contains the
   reference information. This information is also stored in a special file
-  called `<subdir>/.gitrepo`. The presence of this file indicates that the
+  called `<subdir>/.gitrepo/config`. The presence of this file indicates that the
   directory is a subrepo.
 
   All subsequent commands refer to the subrepo by the name of the /subdir/.
@@ -123,13 +123,13 @@ the same arguments. Keep reading…
   this command will do that. It will split out the content of a normal
   subdirectory into a branch and start tracking it as a subrepo. Afterwards
   your original repo will look exactly the same except that there will be a
-  `<subdir>/.gitrepo` file.
+  `<subdir>/.gitrepo/config` file.
 
   If you specify the `--remote` (and optionally the `--branch`) option, the
-  values will be added to the `<subdir>/.gitrepo` file. The `--remote` option
+  values will be added to the `<subdir>/.gitrepo/config` file. The `--remote` option
   is the upstream URL, and the `--branch` option is the upstream branch to push
   to. These values will be needed to do a `git subrepo push` command, but they
-  can be provided later on the `push` command (and saved to `<subdir>/.gitrepo`
+  can be provided later on the `push` command (and saved to `<subdir>/.gitrepo/config`
   if you also specify the `--update` option).
 
   Note: You will need to create the empty upstream repo and push to it on your
@@ -145,11 +145,11 @@ the same arguments. Keep reading…
   Update the subrepo subdir with the latest upstream changes.
 
   The `pull` command fetches the latest content from the remote branch pointed
-  to by the subrepo's `.gitrepo` file, and then tries to merge the changes into
+  to by the subrepo's `.gitrepo/config` file, and then tries to merge the changes into
   the corresponding subdir. It does this by making a branch of the local
   commits to the subdir and then merging or rebasing (see below) it with the
   fetched upstream content. After the merge, the content of the new branch
-  replaces your subdir, the `.gitrepo` file is updated and a single 'pull'
+  replaces your subdir, the `.gitrepo/config` file is updated and a single 'pull'
   commit is added to your mainline history.
 
   The `pull` command will attempt to do the following commands in one go:
@@ -295,9 +295,9 @@ the same arguments. Keep reading…
 
 - `git subrepo config <subdir> <option> [<value>] [-f]`
 
-  Read or update configuration values in the subdir/.gitrepo file.
+  Read or update configuration values in the subdir/.gitrepo/config file.
 
-  Because most of the values stored in the .gitrepo file are generated you
+  Because most of the values stored in the .gitrepo/config file are generated you
   will need to use `--force` if you want to change anything else then the
   `method` option.
 
@@ -359,7 +359,7 @@ the same arguments. Keep reading…
 - `--branch=<branch-name>` (`-b <branch-name>`)
 
   Use a different upstream branch-name than the remote HEAD or the one saved in
-  `.gitrepo` locally.
+  `.gitrepo/config` locally.
 
 - `--dry-run` (`-N`)
 
@@ -397,15 +397,15 @@ the same arguments. Keep reading…
 
 - `--remote=<remote-url>` (`-r <remote-url>`)
 
-  Use a different remote-url than the one saved in `.gitrepo` locally.
+  Use a different remote-url than the one saved in `.gitrepo/config` locally.
 
 - `--squash` (`-s`)
 
   Squash all commits on a push into one new commit.
 
 - `--update` (`-u`)
 
-  If `--branch` or `--remote` are used, and the command updates the `.gitrepo`
+  If `--branch` or `--remote` are used, and the command updates the `.gitrepo/config`
   file, include these values to the update.
 
 = Output Options
@@ -598,7 +598,7 @@ If you want to chat about the `git-subrepo` command, join `#gitcommands` on
 * Works on various Windows environments. See "Windows" section above.
 * The `git-subrepo` repo itself has 2 subrepos under the `ext/` subdirectory.
 * Written in (very modern) Bash, with full test suite. Take a look.
-* A `.gitrepo` file never is in the top level dir (next to a `.git/` dir).
+* A `.gitrepo/config` file never is in the top level dir (next to a `.git/` dir).
 
 = Authors
 

doc/intro-to-subrepo.swim

@@ -194,7 +194,7 @@ Consider the equivalent subrepo commands:
   $ git subrepo pull foo
   $ git subrepo push foo
 
-Collaborators see a file called 'foo/.gitrepo', and know that the subdir is a
+Collaborators see a file called 'foo/.gitrepo/config', and know that the subdir is a
 subrepo. The file contains all the information needed by future commands
 applied to that subrepo.
 
@@ -255,7 +255,7 @@ Given this we do the following steps internally:
 * Read the remote head tree into the index
 * Checkout the index into the new subdir
 * Create a new subrepo commit object for the subdir content
-* Add a state file called .gitrepo to the new subrepo/subdir
+* Add a state file called .gitrepo/config to the new subrepo/subdir
 * Amend the merge commit with this new file
 
 This process adds something like this to the top of your history:
@@ -268,7 +268,7 @@ your history.  This is important as it keeps your history as clean as possible.
 You don't need to have the subrepo history in your main project, since it is
 immutably available elsewhere, and you have a pointer to that place.
 
-The new foo/.gitrepo file looks like this:
+The new foo/.gitrepo/config file looks like this:
 
   [subrepo]
           remote = [email protected]:you/foo.git
@@ -285,7 +285,7 @@ need this url to pull/push in the future.
 
 The next command is the pull command. Normally you just give it the subrepo's
 subdir path (although you can change the branch with -b), and it will get the
-other info from the subdir/.gitrepo file.
+other info from the subdir/.gitrepo/config file.
 
 The pull command does these steps:
 
@@ -294,7 +294,7 @@ The pull command does these steps:
 * Create a branch of local subrepo commits since last pull
 * Rebase this branch onto the upstream commits
 * Commit the HEAD of the rebased content
-* Update/amend the .gitrepo file
+* Update/amend the .gitrepo/config file
 
 === Clean History