{"thread":{"id":"23017","subject":"Dealing with an upstream cherry-picked branch","startedAt":"2010-03-15T04:17:23Z","lastAt":"2010-03-16T22:56:45Z","messageCount":7,"participants":["Jay Soffian","Avery Pennarun","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136789","messageId":"76718491003142117w4fd10449j51deef27548c4d2e@mail.gmail.com","threadId":"23017","inReplyTo":null,"subject":"Dealing with an upstream cherry-picked branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-03-15T04:17:23Z","receivedAt":"2010-03-15T04:17:23Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"I have the following scenario:\n\n  o---o---Ma---o---o    local-master\n /       /\n|       | .-b'------d'  upstream-a\n|       |/  :       :\no---o---a---b---c---d   upstream-master\n\nLocal-master branched from upstream-master in distant past.\nupstream-master periodically cuts tentative release branch upstream-a.\nWhen they do this, that branch point (a) is merged into local-master\n(Ma).\n\nOver time, upstream applies fixes to upstream-a, but does so by\ncommitting the fixes to upstream-master and then cherry-picking them\nto upstream-a.\n\nThe question is how to best integrate the fixes on upstream-a into\nlocal-master, w/o causing a headache when upstream cuts the next\ntentative release branch, at which point upstrea-master will again\nneed to be merged into local-master (and that will also have other\nlocal development). Here are two options I've considered:\n\n1) Create a local-a integration branch, merged from upstream-a and\nlocal-master. Keep this branch up-to-date by periodically merging\nlocal-master and upstream-a:\n\n  o---o---Ma---o---o     local-master\n /       /  \\       \\\n|       |    `o------`o  local-a\n|       |    /       /\n|       | .-b'------d'   upstream-a\n|       |/  :       :\no---o---a---b---c---d    upstream-master\n\n2) Periodically merge upstream-a into local-master:\n\n  o---o---Ma--o---o---o  local-master\n /       /   /       /\n|       | .-b'------d'   upstream-a\n|       |/  :       :\no---o---a---b---c---d    upstream-master\n\nThen when it is next time to merge upstream-master into local-master either:\n\n(a) Backout the upstream-a merges to local-master by reverting the\nmerge commits which introduced them to local-master, then merge\nupstream-master.\n\n(b) Just merge upstream-master and carefully deal with all the\nconflicts. I think this will necessarily be an evil merge.\n\n(c) Create a new branch at point Ma and cherry-pick only the local\ncommits from local-master past point Ma. This essentially gives me the\nclean local-master I would've had if I'd been doing (1) all along.\n\n- Are there any other options I'm missing?\n\n- If I'm going to do (2a), I'm wondering if I'm missing any\nsubtleties. I've read the revert-a-faulty-merge how-to and I realize\nmy history won't be the cleanest, but I think it should work and leave\na picture like:\n\n  o---o---Ma--o---o---o---o---Wd'---Wb'---Mi  local-master\n /       /   /       /                   /\n|       | .-b'------d' upstream-a       |\n|       |/  :       :                   |\no---o---a---b---c---d---e---f---g---h---i    upstream-master\n\nWd' is the revert of d' into local master. Wb' is the revert of b'\ninto local master. This reverts both merges from upstream-a into local\nmaster. There may be conflicts to resolve due to the local changes\nthat happened in local-master. However, local-master should now be\n\"clean\" to merge in upstream-master w/o having to worry about\nconflicts between b and b', d and d'. Correct?\n\nThanks,\n\nj.\n"},{"id":"136865","messageId":"32541b131003151146qeb6b15bqa9317c6d56443e8e@mail.gmail.com","threadId":"23017","inReplyTo":"76718491003142117w4fd10449j51deef27548c4d2e@mail.gmail.com","subject":"Re: Dealing with an upstream cherry-picked branch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-15T18:46:17Z","receivedAt":"2010-03-15T18:46:17Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sun, Mar 14, 2010 at 11:17 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> The question is how to best integrate the fixes on upstream-a into\n> local-master, w/o causing a headache when upstream cuts the next\n> tentative release branch, at which point upstrea-master will again\n> need to be merged into local-master (and that will also have other\n> local development). Here are two options I've considered:\n\nYou forgot option 0: tell upstream not to do that.\n\n0a) Have them do their bugfixes directly in the upstream-a branch,\nthen merge sometimes from upstream-a to upstream-master.  Then when\nthey cut upstream-b from upstream-master, it should be an easy merge\nfor you (since they've already resolved any conflicts between\nupstream-a and upstream-master as they arose over time).\n\n0b) If they really need to do their bugfixes on upstream-master and\nthen cherry-pick them back to upstream-a, have them merge upstream-a\ninto upstream-master sometimes *anyway*, resolving any (probably\ntrivial) conflicts as they arise.  I say the conflicts should be\ntrivial because they're just cherry-picks anyway, so git will mostly\nnotice they're identical and ignore them.  This is easy to do a little\nat a time, but gets more complicated if you wait a long time between\nmerges.\n\n0c) Like 0b), only use 'git merge -s ours' to merge from upstream-a\ninto upstream-master.  This assumes that upstream-a *never* has a fix\nother than one that is already in upstream-master, so that all\nconflicts necessarily resolve to exactly what's already in\nupstream-master.  This makes it easier for downstream people to merge\nbut doesn't actually cost any extra effort.\n\nAs for your original suggestions:\n\n> 1) Create a local-a integration branch, merged from upstream-a and\n> local-master. Keep this branch up-to-date by periodically merging\n> local-master and upstream-a:\n\nThis will be inconvenient since local-master won't actually be useful;\nif upstream-a contains a critical patch, you won't be able to test\nyour changes in local-master until you merge them into local-a.  Thus\nthe history of local-master, while \"clean\", will actually be\nmeaningless.\n\n> 2) Periodically merge upstream-a into local-master:\n> [...]\n> Then when it is next time to merge upstream-master into local-master either:\n>\n> (a) Backout the upstream-a merges to local-master by reverting the\n> merge commits which introduced them to local-master, then merge\n> upstream-master.\n\nDon't try to revert merge commits; that generally ends in disaster,\nboth in terms of your tree's correctness and your ability to\naccurately retrace the history of your branch.  Possibly you can make\nit work, but I don't know anybody who has.  Even if you can, you'll\nstill hate yourself in the morning.\n\n> (b) Just merge upstream-master and carefully deal with all the\n> conflicts. I think this will necessarily be an evil merge.\n\nThis is probably not as hard as it sounds, particularly if upstream-a\nis *purely* a subset (in terms of cherry-picks, not in terms of\nhistory) of upstream-master.  I'd recommend something like this (just\nonce when it's time to move to a new release branch):\n\n       git checkout -b mergey upstream-master\n       # take the history of upstream-a but not the content:\n       git merge -s ours upstream-a\n       # assuming local-master is your branch based on upstream-a:\n       git checkout -b local-b local-master\n       # merge the changes from upstream-a to upstream-master into local-b:\n       git merge mergey\n\n> (c) Create a new branch at point Ma and cherry-pick only the local\n> commits from local-master past point Ma. This essentially gives me the\n> clean local-master I would've had if I'd been doing (1) all along.\n\nThis will work, but the short form for exactly the same operation is:\n\n        git checkout -b local-b local-master\n        git rebase --onto upstream-master upstream-a\n\nIt will result in a cleaner history, and importantly, one that\nupstream would probably be willing to merge someday.  You won't have\nany extra cherry-picked commits confusingly merged into your history\nwith the original commits.\n\nThe disadvantage is that each of your branches will have a disjoint\nhistory: there will be no branch showing how you got from local-a to\nlocal-b, since they're actually two totally different things.  In git,\nthe ideal case is that if you look at the history of HEAD, you can see\nthe *entire* evolution of the product, and using a different\nmerge-base for each branch gets in the way of that.\n\nThe best option above, IMHO, is my proposed option 0.  But any of the\nothers will work.\n\nHave fun,\n\nAvery\n"},{"id":"136873","messageId":"76718491003151407p3cdecf8fx1ddebf19ce304f83@mail.gmail.com","threadId":"23017","inReplyTo":"32541b131003151146qeb6b15bqa9317c6d56443e8e@mail.gmail.com","subject":"Re: Dealing with an upstream cherry-picked branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-03-15T21:07:09Z","receivedAt":"2010-03-15T21:07:09Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 15, 2010 at 2:46 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n> You forgot option 0: tell upstream not to do that.\n\nI have no control over upstream and its currently policy absolutely is\nnot going to change.\n\nHowever, I do have control of my mirror of upstream so...\n\n> 0a) Have them do their bugfixes directly in the upstream-a branch,\n> then merge sometimes from upstream-a to upstream-master.  Then when\n> they cut upstream-b from upstream-master, it should be an easy merge\n> for you (since they've already resolved any conflicts between\n> upstream-a and upstream-master as they arose over time).\n>\n> 0b) If they really need to do their bugfixes on upstream-master and\n> then cherry-pick them back to upstream-a, have them merge upstream-a\n> into upstream-master sometimes *anyway*, resolving any (probably\n> trivial) conflicts as they arise.  I say the conflicts should be\n> trivial because they're just cherry-picks anyway, so git will mostly\n> notice they're identical and ignore them.  This is easy to do a little\n> at a time, but gets more complicated if you wait a long time between\n> merges.\n>\n> 0c) Like 0b), only use 'git merge -s ours' to merge from upstream-a\n> into upstream-master.  This assumes that upstream-a *never* has a fix\n> other than one that is already in upstream-master, so that all\n> conflicts necessarily resolve to exactly what's already in\n> upstream-master.  This makes it easier for downstream people to merge\n> but doesn't actually cost any extra effort.\n\n... I can locally perform the 0b or 0c that they will not do. They\nnever have a fix not already in upstream-master, so I can do 0c.\n[EDIT: I see this is what you suggest below.] I can also put a sanity\ncheck in place to make sure there isn't something unexpected in\nupstream-a.\n\nI will explore this option.\n\n> As for your original suggestions:\n>\n>> 1) Create a local-a integration branch, merged from upstream-a and\n>> local-master. Keep this branch up-to-date by periodically merging\n>> local-master and upstream-a:\n>\n> This will be inconvenient since local-master won't actually be useful;\n> if upstream-a contains a critical patch, you won't be able to test\n> your changes in local-master until you merge them into local-a.  Thus\n> the history of local-master, while \"clean\", will actually be\n> meaningless.\n\nOkay.\n\n>> 2) Periodically merge upstream-a into local-master:\n>> [...]\n>> Then when it is next time to merge upstream-master into local-master either:\n>>\n>> (a) Backout the upstream-a merges to local-master by reverting the\n>> merge commits which introduced them to local-master, then merge\n>> upstream-master.\n>\n> Don't try to revert merge commits; that generally ends in disaster,\n> both in terms of your tree's correctness and your ability to\n> accurately retrace the history of your branch.  Possibly you can make\n> it work, but I don't know anybody who has.  Even if you can, you'll\n> still hate yourself in the morning.\n\nOkay, I'll take this as sage advice. :-)\n\n>> (b) Just merge upstream-master and carefully deal with all the\n>> conflicts. I think this will necessarily be an evil merge.\n>\n> This is probably not as hard as it sounds, particularly if upstream-a\n> is *purely* a subset (in terms of cherry-picks, not in terms of\n> history) of upstream-master.  I'd recommend something like this (just\n> once when it's time to move to a new release branch):\n>\n>       git checkout -b mergey upstream-master\n>       # take the history of upstream-a but not the content:\n>       git merge -s ours upstream-a\n>       # assuming local-master is your branch based on upstream-a:\n>       git checkout -b local-b local-master\n>       # merge the changes from upstream-a to upstream-master into local-b:\n>       git merge mergey\n>\n>> (c) Create a new branch at point Ma and cherry-pick only the local\n>> commits from local-master past point Ma. This essentially gives me the\n>> clean local-master I would've had if I'd been doing (1) all along.\n>\n> This will work, but the short form for exactly the same operation is:\n>\n>        git checkout -b local-b local-master\n>        git rebase --onto upstream-master upstream-a\n\nAre you sure that will skip the merges into local-master from\nupstream-a? I didn't think so and it's not my recollection based on\nusing --onto previously.\n\n> It will result in a cleaner history, and importantly, one that\n> upstream would probably be willing to merge someday.  You won't have\n> any extra cherry-picked commits confusingly merged into your history\n> with the original commits.\n>\n> The disadvantage is that each of your branches will have a disjoint\n> history: there will be no branch showing how you got from local-a to\n> local-b, since they're actually two totally different things.  In git,\n> the ideal case is that if you look at the history of HEAD, you can see\n> the *entire* evolution of the product, and using a different\n> merge-base for each branch gets in the way of that.\n>\n> The best option above, IMHO, is my proposed option 0.  But any of the\n> others will work.\n\nThank you.\n\nj.\n"},{"id":"136876","messageId":"7vocipjmrg.fsf@alter.siamese.dyndns.org","threadId":"23017","inReplyTo":"76718491003142117w4fd10449j51deef27548c4d2e@mail.gmail.com","subject":"Re: Dealing with an upstream cherry-picked branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-15T21:30:43Z","receivedAt":"2010-03-15T21:30:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> I have the following scenario:\n>\n>   o---o---Ma---o---o    local-master\n>  /       /\n> |       | .-b'------d'  upstream-a\n> |       |/  :       :\n> o---o---a---b---c---d   upstream-master\n>\n> Local-master branched from upstream-master in distant past.\n> upstream-master periodically cuts tentative release branch upstream-a.\n> When they do this, that branch point (a) is merged into local-master\n> (Ma).\n>\n> Over time, upstream applies fixes to upstream-a, but does so by\n> committing the fixes to upstream-master and then cherry-picking them\n> to upstream-a.\n>\n> The question is how to best integrate the fixes on upstream-a into\n> local-master, w/o causing a headache when upstream cuts the next\n> tentative release branch, at which point upstrea-master will again\n> need to be merged into local-master (and that will also have other\n> local development). Here are two options I've considered:\n\nIs it an option not to treat \"local-master\" as anything but a throw-away\nintegration testing branch?\n\nPresumably upstream-master would be a stable, non-rewinding branch, and\nwhen they branch for their next release (i.e. at point 'a' in the\npicture), you should be able to trust up to that commit.  So you would\narrange topics on your side to be based on commits before 'a', and never\nlet your people fork from or build directly on local-master.\n\nRebuild local-master every time you would want to run integration testing\nwith the recent upstream changes, either by starting the throw-away\nlocal-master at upstream-master or upstream-a depending on what\ndevelopment phase the upstream is in and what the targetted base for your\nown release, and merging your topics you intend to ship into it.\n\n                  your topics branch from local-base, which was forked\n                  from the last known stable point of the upstream.\n                    /       \\   \\   \\\n                   /         \\   \\   \\  merge topics for integration testing\n                  /           \\   \\   \\\n           ...---o local-base  x---x---x local-master (throw-away)\n                /             /\n    ---o---o---a---b----c----d\n                \\            upstream-master\n                 b'--c'--d'\n                         upstream-a\n\nTo keep track of the set of topics you know you may want to include in the\nupcoming release, you could also merge \"well cooked\" topics into\nlocal-base so that your people can build on top of other topics and test\nthem together.\n\n                  your topics branch from (and possibly\n                  merge into) local-base\n                    / \\   \\       \\   \\ \n                   /   \\   x---x---x---x local-master (throw-away) \n                  /     \\ /   \\\n local-base ..---o---o---o   \\\n                /           /\n    ---o---o---a---b---c---d\n                \\          upstream-master\n                 b'--c'--d'  \n                         upstream-a\n\nAgain, when running integration testing with the recent upstream, you can\nrebuild your throw-away local-master at the tip of local-base, and merge\neither upstream-master or upstream-a to make sure your changes work with\nthem.\n\nIndividual developers can do the same when testing their own topics in\nisolation, together with recent upstream, using their own throw-away\ntesting branches that merge their topic and recent upstream.\n"},{"id":"136902","messageId":"32541b131003151639o173669a7v4b3b4c13bc7e153@mail.gmail.com","threadId":"23017","inReplyTo":"76718491003151407p3cdecf8fx1ddebf19ce304f83@mail.gmail.com","subject":"Re: Dealing with an upstream cherry-picked branch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-15T23:39:41Z","receivedAt":"2010-03-15T23:39:41Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Mar 15, 2010 at 4:07 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> On Mon, Mar 15, 2010 at 2:46 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n>>> Jay Soffian wrote:\n>>> (c) Create a new branch at point Ma and cherry-pick only the local\n>>> commits from local-master past point Ma. This essentially gives me the\n>>> clean local-master I would've had if I'd been doing (1) all along.\n>>\n>> This will work, but the short form for exactly the same operation is:\n>>\n>>        git checkout -b local-b local-master\n>>        git rebase --onto upstream-master upstream-a\n>\n> Are you sure that will skip the merges into local-master from\n> upstream-a? I didn't think so and it's not my recollection based on\n> using --onto previously.\n\nIt should.  The --onto option is rather confusing to get right, and\nbecause git is pretty smart, sometimes the rebase will end up doing\nwhat you want (maybe with some extra conflicts) *despite* using the\nwrong (or no) --onto option.\n\nBasically, the 'upstream-a' option above means \"remove everything\nthat's in upstream-a\" and then the --onto option means \"and then paste\nwhat's left on top of upstream-master\".  Since your merge commits only\nadd things from upstream-a, they too should be left out of the rebase.\n\nSometimes I find this gets confusing.  You can often sort it out by\nusing 'rebase -i' (with otherwise the same options as above) and\ntweaking it a little.  But the upstream-a commits should definitely\nall be gone.\n\nHave fun,\n\nAvery\n"},{"id":"136965","messageId":"76718491003161038u3dc567a7pb0ae558fd3b6b9c9@mail.gmail.com","threadId":"23017","inReplyTo":"7vocipjmrg.fsf@alter.siamese.dyndns.org","subject":"Re: Dealing with an upstream cherry-picked branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-03-16T17:38:31Z","receivedAt":"2010-03-16T17:38:31Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 15, 2010 at 5:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jay Soffian <jaysoffian@gmail.com> writes:\n>\n>> I have the following scenario:\n>>\n>>   o---o---Ma---o---o    local-master\n>>  /       /\n>> |       | .-b'------d'  upstream-a\n>> |       |/  :       :\n>> o---o---a---b---c---d   upstream-master\n>>\n>> Local-master branched from upstream-master in distant past.\n>> upstream-master periodically cuts tentative release branch upstream-a.\n>> When they do this, that branch point (a) is merged into local-master\n>> (Ma).\n>>\n>> Over time, upstream applies fixes to upstream-a, but does so by\n>> committing the fixes to upstream-master and then cherry-picking them\n>> to upstream-a.\n>>\n>> The question is how to best integrate the fixes on upstream-a into\n>> local-master, w/o causing a headache when upstream cuts the next\n>> tentative release branch, at which point upstrea-master will again\n>> need to be merged into local-master (and that will also have other\n>> local development). Here are two options I've considered:\n>\n> Is it an option not to treat \"local-master\" as anything but a throw-away\n> integration testing branch?\n\nOur development is currently very fast paced among a smallish group of\ndevelopers, and so far the developers really prefer to all work on the\nsame branch (i.e, not use topic branches). So they are constantly\npushing their changes to local-master. However, I don't think that\nprecludes an integration branch if I just squint at your picture\nbelow...\n\n> Presumably upstream-master would be a stable, non-rewinding branch, and\n> when they branch for their next release (i.e. at point 'a' in the\n> picture), you should be able to trust up to that commit.  So you would\n> arrange topics on your side to be based on commits before 'a', and never\n> let your people fork from or build directly on local-master.\n>\n> Rebuild local-master every time you would want to run integration testing\n> with the recent upstream changes, either by starting the throw-away\n> local-master at upstream-master or upstream-a depending on what\n> development phase the upstream is in and what the targetted base for your\n> own release, and merging your topics you intend to ship into it.\n>\n>                  your topics branch from local-base, which was forked\n>                  from the last known stable point of the upstream.\n>                    /       \\   \\   \\\n>                   /         \\   \\   \\  merge topics for integration testing\n>                  /           \\   \\   \\\n>           ...---o local-base  x---x---x local-master (throw-away)\n>                /             /\n>    ---o---o---a---b----c----d\n>                \\            upstream-master\n>                 b'--c'--d'\n>                         upstream-a\n>\n> To keep track of the set of topics you know you may want to include in the\n> upcoming release, you could also merge \"well cooked\" topics into\n> local-base so that your people can build on top of other topics and test\n> them together.\n>\n>                  your topics branch from (and possibly\n>                  merge into) local-base\n>                    / \\   \\       \\   \\\n>                   /   \\   x---x---x---x local-master (throw-away)\n>                  /     \\ /   \\\n>  local-base ..---o---o---o   \\\n>                /           /\n>    ---o---o---a---b---c---d\n>                \\          upstream-master\n>                 b'--c'--d'\n>                         upstream-a\n\nBy squinting, I can pretend that all the developers pushes to\nlocal-master are mini \"well cooked\" topics. And I can call my\nthrow-away branch something like, oh say, \"next\". So I will have this\npicture:\n\n                 developer pushes\n                         / \\\n                    -----   \\\n                   /   / \\   \\\nlocal-master ..---o---o---o---o ...    local-master\n                 / \\       \\   \\\n                /   `---o---o---o---o  next\n               /       /           /\n       ---o---a---b---c---d---e---f upstream-master\n               \\\n                b'--c'--d' upstream-a\n\n\nThe merges from upstream-master to next will happen at well-defined\ntimes by an integration manager. The merges from local-master to next\nwill be done by developers themselves to give them exposure to what is\nhappening upstream-master.\n\nBut, it's not clear how that helps me with upstream-a, unless I also\nhave a \"local-a\" branch:\n\nlocal-master ..---o---o---o---o ...    local-master\n                 / \\       \\   \\\n                /   `---o---o---o---o  local-a\n               /       /           /\n       ---o---a---b'--c'----------d'   upstream-a\n\n\nBut now I'm asking for developers to:\n\na) commit changes to local-master\nb) merge to next\nc) merge to local-a\n\n> Again, when running integration testing with the recent upstream, you can\n> rebuild your throw-away local-master at the tip of local-base, and merge\n> either upstream-master or upstream-a to make sure your changes work with\n> them.\n>\n> Individual developers can do the same when testing their own topics in\n> isolation, together with recent upstream, using their own throw-away\n> testing branches that merge their topic and recent upstream.\n\nI think I'm not clear how it helps to make the integration branch\nthrow-away. Unless you mean something like git pu?\n\nLet's assume I want the developers to have the benefit of seeing\nwhat's in upstream-a and upstream-master. Let's also assume the merges\nfrom upstream-master are typically non-trivial. If \"next\" in my\npicture above is something each developer creates themselves, then\nthere is no way to share merge resolutions. That would be painful.\n\nj.\n"},{"id":"136981","messageId":"7vy6hrzxhu.fsf@alter.siamese.dyndns.org","threadId":"23017","inReplyTo":"76718491003161038u3dc567a7pb0ae558fd3b6b9c9@mail.gmail.com","subject":"Re: Dealing with an upstream cherry-picked branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-16T22:56:45Z","receivedAt":"2010-03-16T22:56:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> I think I'm not clear how it helps to make the integration branch\n> throw-away. Unless you mean something like git pu?\n\nThe whole idea of making it throw-away came from that you do not have\ncontrol over your upstream and you would want to work with their\nupstream-master and \"upstream-a of the week\".\n\nI think your squinted version essentially is the same as what I outlined,\nmodulo that your \"local-master\" corresponds to what I called \"local-base\".\nNo matter what we call that branch, as long as you need to be able to\nintegrate cleanly with both upstream-master and the upstream-a (that is\nbuilt by cherry-picking and then thrown away from time to time) and able\nto move forward without too much cruft in your history, \"local-base\" needs\nto stay away from merging upstream-a.\n"}]}