{"thread":{"id":"3560","subject":"Managing topic branches","startedAt":"2006-03-05T01:56:31Z","lastAt":"2006-03-05T10:14:37Z","messageCount":3,"participants":["Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17162","messageId":"7vzmk5lkmo.fsf@assigned-by-dhcp.cox.net","threadId":"3560","inReplyTo":null,"subject":"Managing topic branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T01:56:31Z","receivedAt":"2006-03-05T01:56:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I adopted Tony's excellent \"topic branches\" workflow to manage\nthe topics cooking in separate branches.  The flow goes like\nthis:\n\n - The change to the topic are made as new commits on top of\n   the topic branch.  My naming convention for topic branches\n   are two letters directory under .git/refs/heads/ and short\n   word.  E.g. np/delta for Nico's finer-grained delta work,\n   ml/cvsserver for Martin's git-cvsserver.\n\n - To test topics myself and publish the bleeding edge to\n   others, updated topic branches are merged into \"next\".  If I\n   have some changes to \"master\", the tip of it is also\n   merged into \"next\", so that people following \"next\" will not\n   miss out trivial fixes directly made to \"master\".\n\n - Once a topic is fully cooked, it is merged into \"master\".  I\n   delete the topic branch in my private repository (its tip is\n   already merged into \"master\" and also it was merged into\n   \"next\" long time ago).\n\nThis worked reasonably well, and I can see what are still not in\n\"master\" but brewing in \"next\" with two ways:\n\n - \"git log master..next\".  This is the orthodox way to view\n   list of commits that are in next but still not in next.\n   Giving --no-merges option would help cutting down the\n   cluttering.\n\n - \"git show-branch --topics master 'heads/??/*'\". (note: ??/*\n   is literally given to show-branch to let it glob).\n\nHowever, the former started to break down recently, due to two\nreasons.\n\n1. np/delta turned out to be unsatisfactory, and I had reverts\n   and re-reverts in the topic branch.  Eventually Nico and I\n   decided to throw away the last three commits after merging\n   the earlier bits into \"master\".\n\n        (other topic brances merged into next)\n           \\   \\       \\    \\      \\   \\\n        o---o---o---o---o---o---o---o---o next\n       /           /           /\n      o---o---x---x---x---x---x np/delta\n     /     \\ <-- earlier parts merged\n    o---o---o---o---o master\n\nSome commits on \"np/delta\" merged into \"next\" are reverts and\nthe tip of \"next\" now do not have unwanted bits from the\nfiner-grained delta experiments.  I have dropped np/delta topic\nbranch, so \"show-branch --topics\" does not bother me with these\ncommits marked with 'x' anymore, but \"git log master..next\" will\nkeep showing them\n\n\n2. \"ml/cvsserver\" was initially based on then-current \"next\"\n   tip, because it depended on something else that was only\n   present in \"next\", but by the time I pulled it from Martin,\n   the pieces it depended on have already graduated to \"master\".\n\nSince I wanted to have cvsserver in the \"master\" sooner than\neverything else that were in \"next\" when Martin prepared these\ncommits, I ended up doing this:\n\nHere is what the ancestry graph looked like when I received\ncvsserver stuff:\n\n                        a---b---c ml/cvsserver\n                       /\n          o---o---o---o next\n         /   /   /             A: another topic ml/cvsserver\n        /   A   B*                depended on\n       /     \\                 B*: many other \"unready\" topics\n      o---o---o---o master\n\nSo I cherry-picked them on to \"master\", and merged both\n\"ml/cvsserver\" and \"master\" into \"next\":\n\n                        a---b---c ml/cvsserver\n                       /         \\ <-- questionable octopus leg\n          o---o---o---o-----------* next\n         /   /   /               /  \n        /   o   o               /  \n       /     \\                 /\n      o---o---o---o---a'--b'--c' master\n\nI could have done without the \"questionable octopus leg\", but I\ndid so that when Martin pulled my \"next\" into his cvsserver\nbranch, he does not have to do the real merges [*1*].  But now\ncommits a---b---c comes back to haunt me whenever I do \"git log\nmaster..next\".\n\nThe moral of the story is not to try to be nice to others\nwithout thinking about its concequences ;-).  I should have just\ndone without the \"questionable octopus leg\", and asked Martin to\ndiscard and rebase his tip of the development to my \"next\" after\nthis merge.\n\n\nAnyhow, what I ended up doing to make \"log master..next\" usable\nagain was to cauterize the tips of unwanted topic branches\nmerged into next by merging them into \"master\" branch using\n\"ours\" strategy:\n\n\t$ git checkout master\n\t$ git merge -s ours \"excuse for this\" HEAD ml/cvsserver np/delta\n\nLuckily, I have merged up all the B*'s from \"next\" to \"master\",\nso this was possible, but otherwise until I either merge them to\n\"master\" or decide to drop forever I needed to keep a---b---c\naround in \"log master..next\" output for a loooong time X-<.\n\n\n[Footnote]\n\n*1* I briefly thought about doing this instead, but this is a\nwrong thing to do:\n\n                        a---b---c ml/cvsserver\n                       /         \\       \n          o---o---o---o-------------------* next\n         /   /   /                 \\     /\n        /   A   B*                  \\   / \n       /     \\                       \\ /\n      o---o---o---o-------------------* master\n                   \\                 /\n                    a'------b'------c'\n                     (cherry picked)\n\nAt this point, master would claim to have merged B* but actually\nit has not.\n"},{"id":"17172","messageId":"46a038f90603050135j41eaf935kd48ab68212218836@mail.gmail.com","threadId":"3560","inReplyTo":"7vzmk5lkmo.fsf@assigned-by-dhcp.cox.net","subject":"Re: Managing topic branches","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-03-05T09:35:33Z","receivedAt":"2006-03-05T09:35:33Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:\n> I could have done without the \"questionable octopus leg\", but I\n> did so that when Martin pulled my \"next\" into his cvsserver\n...\n> The moral of the story is not to try to be nice to others\n> without thinking about its concequences ;-).  I should have just\n> done without the \"questionable octopus leg\", and asked Martin to\n> discard and rebase his tip of the development to my \"next\" after\n> this merge.\n\nNo good deed goes unpunished as they say ;-)\n\nIn any case, this was perhaps based on a misunderstanding/error on my\nside. To start off, I didn't understand how you were managing next.\n\nI assumed next would be a 'rewind often' branch, a volatile thing that\nI shouldn't build upon. But as I was in the awkward situation of\ndepending on something in next, I had to, and didn't think of the\nconsequences. As the branch I published for you to pull was based on\nnext, which meant you couldn't merge my stuff into master.\n\nSo it was a thinko on my side. I just though -- damn, I'll have to\nwork based on next, with the downside of having to be alert for\nrewinds. Didn't think of the implications for you.\n\nIt's sorted now, but at great pains for you. I guess all I can suggest\nis to put something in the name of the branch that means both \"rewinds\noften\" and \"don't base real work on this\". I guess that would be\nanything but master/maint, but the rules around pu are sometimes\ntricky too (rewinds often, but some people have no option but to build\nagainst it, unless you are treating it same as you treat next).\n\nAnyway -- sorry to have caused so much trouble. My work \"pending\" is\nat the most a patch or two, easy to extract and reapply. If something\nlike this comes up again, just do whatever is easiest and tell me to\nrewind/rebase/cherrypick at my end.\n\ncheers,\n\n\nmartin\n"},{"id":"17180","messageId":"7vu0adgpv6.fsf@assigned-by-dhcp.cox.net","threadId":"3560","inReplyTo":"46a038f90603050135j41eaf935kd48ab68212218836@mail.gmail.com","subject":"Re: Managing topic branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T10:14:37Z","receivedAt":"2006-03-05T10:14:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" <martin.langhoff@gmail.com> writes:\n\n> In any case, this was perhaps based on a misunderstanding/error on my\n> side. To start off, I didn't understand how you were managing next.\n\nNo nononononono nooooo.\n\nIf I sounded like you were the guilty party I apologize.  I did\nnot mean it that way.\n\nIt was my mistake.  I encouraged people to experiment and build\nupon \"next\".  It was just the way I pulled the stuff in was bad.\n"}]}