[Q] Branch aliases (synonyms)?

[Q] Branch aliases (synonyms)?

[Brian Foster]

 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
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

Re: [Q] Branch aliases (synonyms)?

[Hallvard Breien Furuseth]

 Brian Foster wrote:
> (...)
>  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?

 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

>   ▶ Are there other solutions?

 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

Re: [Q] Branch aliases (synonyms)?

[Hallvard Breien Furuseth]

 I wrote:
> Possibly in addition to them using a private symref.  In this
> case, 'git symbolic-ref B refs/heads/A' might work better.

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

 Hallvard

Re: [Q] Branch aliases (synonyms)?

[Brian Foster]

On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:
> Brian Foster wrote:
> > (...)
> >  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?
> 
>  Git clone will turn symref B into a regular branch,
>  which will not move in parallel with A.

 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. )

>  People may have private scripts which will
>  be surprised when they encounter B.  E.g. when
>  parsing the output from 'git branch'.

 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).

>[ ... ]
> >   ▶ Are there other solutions?
> 
>  You haven't explained the problem which led you to want "equal"
>  branches.

 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. )

>             E.g. if it's hard to teach developers to switch
>  from B to A, a hook which rejects pushes to B might help.

 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-

>  Possibly in addition to them using a private symref.  In this
>  case, [ suggestion deleted as the author confirms it is in error ].
> 
>  Hallvard

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

Re: [Q] Branch aliases (synonyms)?

[Michael Haggerty]

On 07/03/2012 03:40 PM, Brian Foster wrote:
> On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:
>>              E.g. if it's hard to teach developers to switch
>>   from B to A, a hook which rejects pushes to B might help.
>
>   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.

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

-- 
Michael Haggerty
mhagger@alum.mit.edu

Re: [Q] Branch aliases (synonyms)?

[Johan Herland]

On Tue, Jul 3, 2012 at 3:40 PM, Brian Foster <brian.foster@maxim-ic.com> wrote:
> On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:
>> Brian Foster wrote:
>> > (...)
>> >  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?
>>
>>  Git clone will turn symref B into a regular branch,
>>  which will not move in parallel with A.
>
>  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.”

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

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [Q] Branch aliases (synonyms)?

[Hallvard Breien Furuseth]

 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

Re: [Q] Branch aliases (synonyms)?

[Brian Foster]

On Tuesday 03-July-2012 10:49:39 Hallvard Breien Furuseth wrote:
>[ ... ]
>  Yes, a symref in the master repo only seems tidy enough.
>  I should have realized that's what he meant.

 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).

>  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:)

 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.

>  And if you haven't already, it may be best to do
> 
>    git config --bool receive.denyNonFastForwards  true
>    git config --bool receive.denyDeletes          true

 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-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Office:  +33 (0)4 42 98 15 35  |  Fax:  +33 (0)4 42 08 33 19
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

Re: [Q] Branch aliases (synonyms)?

[Brian Foster]

On Tuesday 03-July-2012 08:29:26 Michael Haggerty wrote:
> On 07/03/2012 03:40 PM, Brian Foster wrote:
> > On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:
> >>              E.g. if it's hard to teach developers to switch
> >>   from B to A, a hook which rejects pushes to B might help.
> >
> >   Whilst we _may_ have problems with some of the
> >   internal developers [...], 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.
> 
> 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.

 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-
-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

Re: [Q] Branch aliases (synonyms)?

[Hallvard Breien Furuseth]

 On Wed, 4 Jul 2012 09:24:27 +0200, Brian Foster 
 <brian.foster@maxim-ic.com> wrote:
> On Tuesday 03-July-2012 10:49:39 Hallvard Breien Furuseth wrote:
>>[ ... ]
>>  Yes, a symref in the master repo only seems tidy enough.
>>  I should have realized that's what he meant.
>
>  My apologies.  I just re-read my original Question,
>  and realize I failed to make that clear.

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

 Hallvard

Re: [Q] Branch aliases (synonyms)?

[Brian Foster]

On Wednesday 04-July-2012 00:31:40 Brian Foster wrote:
> On Tuesday 03-July-2012 08:29:26 Michael Haggerty wrote:
> > On 07/03/2012 03:40 PM, Brian Foster wrote:
> > > On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:
> > >>              E.g. if it's hard to teach developers to switch
> > >>   from B to A, a hook which rejects pushes to B might help.
> > >
> > > [ ... ]                    the concern is about the
> > >  external users (clients who clone but never push)
> > >  becoming confused.  [ ... ]
> > 
> > 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.
> 
>  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”  [ ... ]).

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-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/