From: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
Date: Tue, 03 Jul 2012 17:49:39 GMT
Subject: Re: [Q] Branch aliases (synonyms)?
Message-ID: <93495bc04d9f7426bef1b1de1b202280@ulrik.uio.no>
In-Reply-To: <CALKQrgeAXLSwsqwTe_FZN0aNHwnoSBHBt+PO9jpCtzRM1Aeyrw@mail.gmail.com>

 On Tue, 3 Jul 2012 18:22:43 +0200, Johan Herland <johan@herland.net> 
 wrote:
> 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