{"thread":{"id":"30943","subject":"[Q] Branch aliases (synonyms)?","startedAt":"2012-07-03T10:39:24Z","lastAt":"2012-07-05T07:06:19Z","messageCount":11,"participants":["Brian Foster","Hallvard Breien Furuseth","Michael Haggerty","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194522","messageId":"1919214.YKUdgul2iY@laclwks004","threadId":"30943","inReplyTo":null,"subject":"[Q] Branch aliases (synonyms)?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-07-03T10:39:24Z","receivedAt":"2012-07-03T10:39:24Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"\n Having fought and lost a battle not to do this,\n we are currently planning on transitioning from\n the old version (called ‘A’ below) to the new\n (called ‘B’) by creating a TEMPORARY branch for\n the new work, and at the end of the transition,\n merging it into the old, which is then the only\n branch. That is, at the end we have something\n like the following:\n\n /--a---a----------\\\n ...--o---o n---n---A (HEAD)\n \\--b---b---b---b--/\n\n with a starting-point of:\n\n ...--o---A (HEAD)\n\n and with during-transition intermediate points\n similar to:\n\n /--a---A\n ...--*---*\n \\--b---b---B (HEAD)\n\n None of which isn't a problem per se.\n\n The catch is a desire(? requirement?) that, when the\n transition ends, people used to using B can continue\n to use B, people used to using A can continue to use A,\n and there is no difference. That is, after the end of\n transition, branch names A and B are the same thing.\n Always. Automatically.\n\n Using a symref seems a working answer. That is,\n after the merge, change B from a true branch head\n into a symref pointing to A:\n\n git merge ...\n git symbolic-ref refs/heads/B refs/heads/A\n\n ▶ What are the gotchas?\n ▶ Are there other solutions?\n\n I have written a test script to explore the idea,\n and it seems to be working. The script is a bit\n on the long side (c.500 lines) since it is trying\n to exercise a number of different cases, so I\n won't post it unless asked.\n\ncheers!\n\t-blf-\n\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"},{"id":"194524","messageId":"93cfd6eb9045585728dfe649359a103c@ulrik.uio.no","threadId":"30943","inReplyTo":"1919214.YKUdgul2iY@laclwks004","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-07-03T12:23:29Z","receivedAt":"2012-07-03T12:23:29Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" Brian Foster wrote:\n> (...)\n> The catch is a desire(? requirement?) that, when the\n> transition ends, people used to using B can continue\n> to use B, people used to using A can continue to use A,\n> and there is no difference. That is, after the end of\n> transition, branch names A and B are the same thing.\n> Always. Automatically.\n>\n> Using a symref seems a working answer. That is,\n> after the merge, change B from a true branch head\n> into a symref pointing to A:\n>\n> git merge ...\n> git symbolic-ref refs/heads/B refs/heads/A\n>\n> ▶ What are the gotchas?\n\n Git clone will turn symref B into a regular branch,\n which will not move in parallel with A.\n\n People may have private scripts which will\n be surprised when they encounter B. E.g. when\n parsing the output from 'git branch'.\n Check out B, then you expect B rather than A\n to be reported as the current branch:\n git checkout B\n git branch\n * A\n B -> A\n\n> ▶ Are there other solutions?\n\n You haven't explained the problem which led you to want \"equal\"\n branches. E.g. if it's hard to teach developers to switch\n from B to A, a hook which rejects pushes to B might help.\n Possibly in addition to them using a private symref. In this\n case, 'git symbolic-ref B refs/heads/A' might work better.\n\n Hallvard\n"},{"id":"194525","messageId":"2d971099da6c66369be0afb7f8bc19d4@ulrik.uio.no","threadId":"30943","inReplyTo":"93cfd6eb9045585728dfe649359a103c@ulrik.uio.no","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-07-03T12:36:57Z","receivedAt":"2012-07-03T12:36:57Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" I wrote:\n> Possibly in addition to them using a private symref. In this\n> case, 'git symbolic-ref B refs/heads/A' might work better.\n\n Whoops, bad idea - git checkout B then gives a detached HEAD.\n\n Hallvard\n"},{"id":"194526","messageId":"4261222.bYBuBBxnOa@laclwks004","threadId":"30943","inReplyTo":"93cfd6eb9045585728dfe649359a103c@ulrik.uio.no","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-07-03T13:40:13Z","receivedAt":"2012-07-03T13:40:13Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:\n> Brian Foster wrote:\n> > (...)\n> > The catch is a desire(? requirement?) that, when the\n> > transition ends, people used to using B can continue\n> > to use B, people used to using A can continue to use A,\n> > and there is no difference. That is, after the end of\n> > transition, branch names A and B are the same thing.\n> > Always. Automatically.\n> >\n> > Using a symref seems a working answer. That is,\n> > after the merge, change B from a true branch head\n> > into a symref pointing to A:\n> >\n> > git merge ...\n> > git symbolic-ref refs/heads/B refs/heads/A\n> >\n> > ▶ What are the gotchas?\n> \n> Git clone will turn symref B into a regular branch,\n> which will not move in parallel with A.\n\n Yes, I realize that (and my test script shows it).\n But I'm not concerned about it — albeit I've yet\n to check with my colleagues — because it matters\n only if you _expect_ the two to be identical in\n clones at all times. That wasn't the requirement.\n The (and I must say I _do_ think this is silly!)\n requirement is “People used to using A can still\n use A. People used to using B can still use B.”\n\n ( Having said that, I now realize my comment\n that “... and there is no difference” could be\n misconstrued. My apologies. Sorry! What I _meant_\n was the two classes of user (A users and B users)\n could work in an identical fashion except for\n the name difference. )\n\n> People may have private scripts which will\n> be surprised when they encounter B. E.g. when\n> parsing the output from 'git branch'.\n\n YES. This is a good point, but in this case\n should not apply: The only repository with\n the symref is not directly accessible, so,\n with a few expert exceptions, everyone is\n using clones (often cloned from a mirror,\n which doesn't have the symref being a clone).\n\n>[ ... ]\n> > ▶ Are there other solutions?\n> \n> You haven't explained the problem which led you to want \"equal\"\n> branches.\n\n People who don't know what they are doing\n making detailed technical requirements and\n not listening-to advice from the experts.\n I myself want to avoid the whole two-branch\n merge business, or, if not possible, then\n do the obvious thing and delete one of the\n branch names (B) after the merge, yadda-yadda.\n ( I do have a vague hope of removing this\n branch alias “requirement”, but not of\n removing the two-branches-then-merge plan. )\n\n> E.g. if it's hard to teach developers to switch\n> from B to A, a hook which rejects pushes to B might help.\n\n Whilst we _may_ have problems with some of the\n internal developers (this can be managed so I'm\n not worried about it), the concern is about the\n external users (clients who clone but never push)\n becoming confused. Hence the requirement about\n continuing to use the same branch name as you are\n used to using. That's it! It's that simple.\n\nThanks,\n\t-blf-\n\n> Possibly in addition to them using a private symref. In this\n> case, [ suggestion deleted as the author confirms it is in error ].\n> \n> Hallvard\n\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"},{"id":"194527","messageId":"4FF30FD6.6020501@alum.mit.edu","threadId":"30943","inReplyTo":"4261222.bYBuBBxnOa@laclwks004","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-07-03T15:29:26Z","receivedAt":"2012-07-03T15:29:26Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 07/03/2012 03:40 PM, Brian Foster wrote:\n> On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:\n>> E.g. if it's hard to teach developers to switch\n>> from B to A, a hook which rejects pushes to B might help.\n>\n> Whilst we _may_ have problems with some of the\n> internal developers (this can be managed so I'm\n> not worried about it), the concern is about the\n> external users (clients who clone but never push)\n> becoming confused. Hence the requirement about\n> continuing to use the same branch name as you are\n> used to using. That's it! It's that simple.\n\nMaybe create a new branch B (an orphan commit unconnected to the old \nbranch B) with a single README file telling the person that from now on \nthey should be using branch A.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"194528","messageId":"CALKQrgeAXLSwsqwTe_FZN0aNHwnoSBHBt+PO9jpCtzRM1Aeyrw@mail.gmail.com","threadId":"30943","inReplyTo":"4261222.bYBuBBxnOa@laclwks004","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2012-07-03T16:22:43Z","receivedAt":"2012-07-03T16:22:43Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tue, Jul 3, 2012 at 3:40 PM, Brian Foster wrote:\n> On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:\n>> Brian Foster wrote:\n>> > (...)\n>> > The catch is a desire(? requirement?) that, when the\n>> > transition ends, people used to using B can continue\n>> > to use B, people used to using A can continue to use A,\n>> > and there is no difference. That is, after the end of\n>> > transition, branch names A and B are the same thing.\n>> > Always. Automatically.\n>> >\n>> > Using a symref seems a working answer. That is,\n>> > after the merge, change B from a true branch head\n>> > into a symref pointing to A:\n>> >\n>> > git merge ...\n>> > git symbolic-ref refs/heads/B refs/heads/A\n>> >\n>> > ▶ What are the gotchas?\n>>\n>> Git clone will turn symref B into a regular branch,\n>> which will not move in parallel with A.\n>\n> Yes, I realize that (and my test script shows it).\n> But I'm not concerned about it — albeit I've yet\n> to check with my colleagues — because it matters\n> only if you _expect_ the two to be identical in\n> clones at all times. That wasn't the requirement.\n> The (and I must say I _do_ think this is silly!)\n> requirement is “People used to using A can still\n> use A. People used to using B can still use B.”\n\nFWIW, we have done a similar thing at $dayjob: A git repo (originally\nconverted form Subversion) still used \"trunk\" as the main development\nbranch. We wanted to start following Git conventions, so we renamed it\nto \"master\", and set up \"trunk\" as a symref to \"master\". We then told\nall the other developers that \"trunk\" is now \"master\", and that they\nshould switch at their own leisure. After a grace period, we will\nremove the \"trunk\" symref.\n\nAFAICS, this seems to work very well. People in old clones keep\nworking on \"trunk\" for as long as they like. They push their work back\nto \"trunk\" on the server, which follows/preserves the symref, and\nupdates the \"master\" branch. People in new clones get the \"master\"\nbranch automatically, and push their work directly back to the\nserver's \"master\". Obviously, all clones also get the other branch\nwhen they fetch from the server, but so far nobody has gotten confused\nby this other branch that \"mysteriously\" follows their \"main\" branch.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"194536","messageId":"93495bc04d9f7426bef1b1de1b202280@ulrik.uio.no","threadId":"30943","inReplyTo":"CALKQrgeAXLSwsqwTe_FZN0aNHwnoSBHBt+PO9jpCtzRM1Aeyrw@mail.gmail.com","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-07-03T17:49:39Z","receivedAt":"2012-07-03T17:49:39Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Tue, 3 Jul 2012 18:22:43 +0200, Johan Herland \n wrote:\n> FWIW, we have done a similar thing at $dayjob: A git repo (originally\n> converted form Subversion) still used \"trunk\" as the main development\n> branch. We wanted to start following Git conventions, so we renamed \n> it\n> to \"master\", and set up \"trunk\" as a symref to \"master\". We then told\n> all the other developers that \"trunk\" is now \"master\", and that they\n> should switch at their own leisure. After a grace period, we will\n> remove the \"trunk\" symref.\n> (...)\n\n Yes, a symref in the master repo only seems tidy enough.\n I should have realized that's what he meant.\n\n I can think of one irritant to warn developers of:\n\n git fetch # Fetches both A and B\n git checkout A # Lemme see how this looks for A users...\n ...\n git checkout B # My scripts are still using B though...\n ...commit something...\n git push # Pushes B, doesn't know remote A is forwarded\n git push # Rejected, non-fast-forward of your old A\n\n \"WTF, why does that keep happening all the time?\"\n\n git branch -d A # Fixes the above (if A is not checked out:)\n\n\n And if you haven't already, it may be best to do\n\n git config --bool receive.denyNonFastForwards true\n git config --bool receive.denyDeletes true\n\n just in case someone gets too clever and does something like:\n \"Now how do I get rid of the remote A? Google... Aha\"\n git push origin :refs/heads/A # whoops, wrong A deleted:-)\n\n Hallvard\n"},{"id":"194604","messageId":"1352871.G8Zbg5HGke@laclwks004","threadId":"30943","inReplyTo":"93495bc04d9f7426bef1b1de1b202280@ulrik.uio.no","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-07-04T07:24:27Z","receivedAt":"2012-07-04T07:24:27Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"On Tuesday 03-July-2012 10:49:39 Hallvard Breien Furuseth wrote:\n>[ ... ]\n> Yes, a symref in the master repo only seems tidy enough.\n> I should have realized that's what he meant.\n\n My apologies. I just re-read my original Question,\n and realize I failed to make that clear. YES, the\n only place there would be a symref is in the master\n repo (we call it the “main” repo).\n\n> I can think of one irritant to warn developers of:\n> \n> git fetch # Fetches both A and B\n> git checkout A # Lemme see how this looks for A users...\n> ...\n> git checkout B # My scripts are still using B though...\n> ...commit something...\n> git push # Pushes B, doesn't know remote A is forwarded\n> git push # Rejected, non-fast-forward of your old A\n> \n> \"WTF, why does that keep happening all the time?\"\n> \n> git branch -d A # Fixes the above (if A is not checked out:)\n\n No developer can push to “main” (we use Gerrit as\n a front-end / staging-area), Approved Patches go\n from Gerrit → “main” (both internal) and then on\n to the externally-accessible mirrors. The clients\n pull/fetch from the mirrors, and cannot push to any\n of the Gerrit, “main”, or the mirrors.\n \n Any feedback from the clients — which is Very Rare\n (not sure if that's Good or Bad?) — is currently\n done via e-mail, which is put into Gerrit as per\n the usual process.\n\n Nonetheless, your point is quite valid. We would\n have to warn developers (and the clients) about\n switch-ing back and forth between A and B. This\n is one reason I myself am less-than-keen on the\n idea, along with not liking the merge plan anyways.\n\n> And if you haven't already, it may be best to do\n> \n> git config --bool receive.denyNonFastForwards true\n> git config --bool receive.denyDeletes true\n\n Ah! That seems like a Good Idea, regardless of whether\n we do this symref'ing or not. Many Thanks for the tip!\n\n We do have some access controls, both a front-end and\n hook(s?), on the mirrors which are supposed to prevent\n those sort of things (and other abuses), but I have no\n objection to yet another barrier / protective measure.\n\ncheers!\n\t-blf-\n\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nOffice: +33 (0)4 42 98 15 35 | Fax: +33 (0)4 42 08 33 19\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"},{"id":"194606","messageId":"4417201.NtYkVMYjv0@laclwks004","threadId":"30943","inReplyTo":"4FF30FD6.6020501@alum.mit.edu","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-07-04T07:31:40Z","receivedAt":"2012-07-04T07:31:40Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"On Tuesday 03-July-2012 08:29:26 Michael Haggerty wrote:\n> On 07/03/2012 03:40 PM, Brian Foster wrote:\n> > On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:\n> >> E.g. if it's hard to teach developers to switch\n> >> from B to A, a hook which rejects pushes to B might help.\n> >\n> > Whilst we _may_ have problems with some of the\n> > internal developers [...], the concern is about the\n> > external users (clients who clone but never push)\n> > becoming confused. Hence the requirement about\n> > continuing to use the same branch name as you are\n> > used to using. That's it! It's that simple.\n> \n> Maybe create a new branch B (an orphan commit unconnected\n> to the old branch B) with a single README file telling the\n> person that from now on they should be using branch A.\n\n Hum.... This idea, at first glance, looks\n extremely intriguing (with, perhaps, the minor\n tweak there is also a ‘Makefile’ which shows\n the ‘READ_ME’ and then always “fails” — That\n would fit better into how the overall system\n works / is typically used). I will run it by\n my colleagues, and if they think it can fly,\n will try some tests. Many Thanks!\n\ncheers!\n\t-blf-\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"},{"id":"194610","messageId":"94ec6b25688da913c10f063b6ccfe838@ulrik.uio.no","threadId":"30943","inReplyTo":"1352871.G8Zbg5HGke@laclwks004","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2012-07-04T09:55:50Z","receivedAt":"2012-07-04T09:55:50Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Wed, 4 Jul 2012 09:24:27 +0200, Brian Foster \n wrote:\n> On Tuesday 03-July-2012 10:49:39 Hallvard Breien Furuseth wrote:\n>>[ ... ]\n>> Yes, a symref in the master repo only seems tidy enough.\n>> I should have realized that's what he meant.\n>\n> My apologies. I just re-read my original Question,\n> and realize I failed to make that clear.\n\n That's alright, I proficient at asking unclear questions myself.\n\n Hallvard\n"},{"id":"194631","messageId":"4406023.HK6z7GB5ye@laclwks004","threadId":"30943","inReplyTo":"4417201.NtYkVMYjv0@laclwks004","subject":"Re: [Q] Branch aliases (synonyms)?","fromName":"Brian Foster","fromEmail":"brian.foster@maxim-ic.com","sentAt":"2012-07-05T07:06:19Z","receivedAt":"2012-07-05T07:06:19Z","isPatch":false,"sender":{"key":"brian.foster@maxim-ic.com","avatar":null},"body":"On Wednesday 04-July-2012 00:31:40 Brian Foster wrote:\n> On Tuesday 03-July-2012 08:29:26 Michael Haggerty wrote:\n> > On 07/03/2012 03:40 PM, Brian Foster wrote:\n> > > On Tuesday 03-July-2012 05:23:29 Hallvard Breien Furuseth wrote:\n> > >> E.g. if it's hard to teach developers to switch\n> > >> from B to A, a hook which rejects pushes to B might help.\n> > >\n> > > [ ... ] the concern is about the\n> > > external users (clients who clone but never push)\n> > > becoming confused. [ ... ]\n> > \n> > Maybe create a new branch B (an orphan commit unconnected\n> > to the old branch B) with a single README file telling the\n> > person that from now on they should be using branch A.\n> \n> Hum.... This idea, at first glance, looks\n> extremely intriguing (with, perhaps, the minor\n> tweak there is also a ‘Makefile’ which shows\n> the ‘READ_ME’ and then always “fails” [ ... ]).\n\nMichael,\n\n Thanks for this idea! With my ‘Makefile’ tweak,\n the idea has caught fire, and is now the preferred\n solution. Whilst I have not yet finished updating\n my model to test it, it is extremely promising.\n\ncheers,\n\t-blf-\n\n-- \nBrian Foster\nPrincipal MTS, Software | La Ciotat, France\nMaxim Integrated Products | Web: http://www.maxim-ic.com/\n"}]}