[Q] Branch aliases (synonyms)?

 Having fought and lost a battle not to do this,
 we are currently planning on transitioning from
 the old version (called ‘A’ below) to the new
 (called ‘B’) by creating a TEMPORARY branch for
 the new work, and at the end of the transition,
 merging it into the old, which is then the only
 branch.  That is, at the end we have something
 like the following:

            /--a---a----------\
  ...--o---o                   n---n---A (HEAD)
            \--b---b---b---b--/

 with a starting-point of:

  ...--o---A (HEAD)

 and with during-transition intermediate points
 similar to:

            /--a---A
  ...--*---*
            \--b---b---B (HEAD)

 None of which isn't a problem per se.

 The catch is a desire(? requirement?) that, when the
 transition ends, people used to using B can continue
 to use B, people used to using A can continue to use A,
 and there is no difference.  That is, after the end of
 transition, branch names A and B are the same thing.
 Always.  Automatically.

 Using a symref seems a working answer.  That is,
 after the merge, change B from a true branch head
 into a symref pointing to A:

      git merge ...
      git symbolic-ref refs/heads/B refs/heads/A

  ▶ What are the gotchas?
  ▶ Are there other solutions?

 I have written a test script to explore the idea,
 and it seems to be working.  The script is a bit
 on the long side (c.500 lines) since it is trying
 to exercise a number of different cases, so I
 won't post it unless asked.

cheers!
	-blf-

 Brian Foster wrote:

 Git clone will turn symref B into a regular branch,
 which will not move in parallel with A.

 People may have private scripts which will
 be surprised when they encounter B.  E.g. when
 parsing the output from 'git branch'.
 Check out B, then you expect B rather than A
 to be reported as the current branch:
   git checkout B
   git branch
   * A
     B -> A

 You haven't explained the problem which led you to want "equal"
 branches.  E.g. if it's hard to teach developers to switch
 from B to A, a hook which rejects pushes to B might help.
 Possibly in addition to them using a private symref.  In this
 case, 'git symbolic-ref B refs/heads/A' might work better.

 Hallvard

 I wrote:

 Whoops, bad idea - git checkout B then gives a detached HEAD.

 Hallvard

On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:

 Yes, I realize that (and my test script shows it).
 But I'm not concerned about it  — albeit I've yet
 to check with my colleagues —  because it matters
 only if you _expect_ the two to be identical in
 clones at all times.  That wasn't the requirement.
 The (and I must say I _do_ think this is silly!)
 requirement is “People used to using A can still
 use A.  People used to using B can still use B.”

 ( Having said that, I now realize my comment
  that “... and there is no difference” could be
  misconstrued.  My apologies.  Sorry!  What I _meant_
  was the two classes of user (A users and B users)
  could work in an identical fashion except for
  the name difference. )

 YES.  This is a good point, but in this case
 should not apply:  The only repository with
 the symref is not directly accessible, so,
 with a few expert exceptions, everyone is
 using clones (often cloned from a mirror,
 which doesn't have the symref being a clone).

 People who don't know what they are doing
 making detailed technical requirements and
 not listening-to advice from the experts.
 I myself want to avoid the whole two-branch
 merge business, or, if not possible, then
 do the obvious thing and delete one of the
 branch names (B) after the merge, yadda-yadda.
 ( I do have a vague hope of removing this
  branch alias “requirement”, but not of
  removing the two-branches-then-merge plan. )

 Whilst we _may_ have problems with some of the
 internal developers (this can be managed so I'm
 not worried about it), the concern is about the
 external users (clients who clone but never push)
 becoming confused.  Hence the requirement about
 continuing to use the same branch name as you are
 used to using.  That's it!  It's that simple.

Thanks,
	-blf-

On 07/03/2012 03:40 PM, Brian Foster wrote:

Maybe create a new branch B (an orphan commit unconnected to the old branch B) with a single README file telling the person that from now on they should be using branch A.

Michael

On Tuesday 03-July-2012 08:29:26 Michael Haggerty wrote:

 Hum....  This idea, at first glance, looks
 extremely intriguing (with, perhaps, the minor
 tweak there is also a ‘Makefile’ which shows
 the ‘READ_ME’ and then always “fails”  —  That
 would fit better into how the overall system
 works / is typically used).  I will run it by
 my colleagues, and if they think it can fly,
 will try some tests.  Many Thanks!

cheers!
	-blf-

On Wednesday 04-July-2012 00:31:40 Brian Foster wrote:

Michael,

 Thanks for this idea!  With my ‘Makefile’ tweak,
 the idea has caught fire, and is now the preferred
 solution.  Whilst I have not yet finished updating
 my model to test it, it is extremely promising.

cheers,
	-blf-

On Tue, Jul 3, 2012 at 3:40 PM, Brian Foster <brian.foster@maxim-ic.com> 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.

AFAICS, this seems to work very well. People in old clones keep working on "trunk" for as long as they like. They push their work back to "trunk" on the server, which follows/preserves the symref, and updates the "master" branch. People in new clones get the "master" branch automatically, and push their work directly back to the server's "master". Obviously, all clones also get the other branch when they fetch from the server, but so far nobody has gotten confused by this other branch that "mysteriously" follows their "main" branch.

Have fun! :)

...Johan

 On Tue, 3 Jul 2012 18:22:43 +0200, Johan Herland <johan@herland.net> 
 wrote:

 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

On Tuesday 03-July-2012 10:49:39 Hallvard Breien Furuseth wrote:

 My apologies.  I just re-read my original Question,
 and realize I failed to make that clear.  YES, the
 only place there would be a symref is in the master
 repo (we call it the “main” repo).

 No developer can push to “main” (we use Gerrit as
 a front-end / staging-area),  Approved Patches go
 from Gerrit → “main” (both internal) and then on
 to the externally-accessible mirrors.  The clients
 pull/fetch from the mirrors, and cannot push to any
 of the Gerrit, “main”, or the mirrors.
 
 Any feedback from the clients  — which is Very Rare
 (not sure if that's Good or Bad?) —  is currently
 done via e-mail, which is put into Gerrit as per
 the usual process.

 Nonetheless, your point is quite valid.  We would
 have to warn developers (and the clients) about
 switch-ing back and forth between A and B.  This
 is one reason I myself am less-than-keen on the
 idea, along with not liking the merge plan anyways.

 Ah!  That seems like a Good Idea, regardless of whether
 we do this symref'ing or not.  Many Thanks for the tip!

 We do have some access controls, both a front-end and
 hook(s?), on the mirrors which are supposed to prevent
 those sort of things (and other abuses), but I have no
 objection to yet another barrier / protective measure.

cheers!
	-blf-

 On Wed, 4 Jul 2012 09:24:27 +0200, Brian Foster 
 <brian.foster@maxim-ic.com> wrote:

 That's alright, I proficient at asking unclear questions myself.

 Hallvard