contrib: New remotes structure for vendor and personal refs
commit24b178184f260a6ec1516cfb8bb8876874a078a7
authorRichard Earnshaw <rearnsha@arm.com>
Mon, 20 Jan 2020 10:37:29 +0000 (20 10:37 +0000)
committerRichard Earnshaw <rearnsha@arm.com>
Mon, 20 Jan 2020 10:37:29 +0000 (20 10:37 +0000)
tree2ad276e7a75d463622b58e01a8bc3ee2ac7b6b2a
parent0757f0bbf3edf43a27ec3f7d2c33ab56f26eb15a
contrib: New remotes structure for vendor and personal refs

The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository).  Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location.  This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.

To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space.  The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.

As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.

You might, however, want to run
  git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
  git fetch vendors/<vendor>
or
  git fetch <me>
to re-populate the remotes/ structures.

Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
  git config branch.<name>.remote <new-remote>

so that merges and pushes go to the right place (I haven't attempted
to automate this last part).

For vendors, the new structure means that

  git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>

will correctly set up a remote tracking branch.

Please be aware that if you have multiple personal branches set up, then

  git push <me>

will still consider all of them for pushing.  If you only want to push
one branch, then either write
  git push <me> HEAD
or
  git push <me> <me>/branch
as appropriate.

And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.

Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh.  If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream.  If you re-run the
script for the same vendor without the option, the push spec will be
removed.

* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting.  Use a separate remotes for the
personal commit area.  Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout.  Add --enable-push
option.
contrib/ChangeLog
contrib/gcc-git-customization.sh
contrib/git-fetch-vendor.sh