Show 9 quoted lines
> FWIW, we have done a similar thing at $dayjob: A git repo (originally
> converted form Subversion) still used "trunk" as the main development
> branch. We wanted to start following Git conventions, so we renamed
> it
> to "master", and set up "trunk" as a symref to "master". We then told
> all the other developers that "trunk" is now "master", and that they
> should switch at their own leisure. After a grace period, we will
> remove the "trunk" symref.
> (...)
Yes, a symref in the master repo only seems tidy enough.
I should have realized that's what he meant.
I can think of one irritant to warn developers of:
git fetch # Fetches both A and B
git checkout A # Lemme see how this looks for A users...
...
git checkout B # My scripts are still using B though...
...commit something...
git push # Pushes B, doesn't know remote A is forwarded
git push # Rejected, non-fast-forward of your old A
"WTF, why does that keep happening all the time?"
git branch -d A # Fixes the above (if A is not checked out:)
And if you haven't already, it may be best to do
git config --bool receive.denyNonFastForwards true
git config --bool receive.denyDeletes true
just in case someone gets too clever and does something like:
"Now how do I get rid of the remote A? Google... Aha"
git push origin :refs/heads/A # whoops, wrong A deleted:-)
Hallvard