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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html