{"thread":{"id":"55534","subject":"Track changes across multiple branches, c.f. \"p4 interchanges\" ?","startedAt":"2021-04-21T09:54:01Z","lastAt":"2021-04-26T21:35:00Z","messageCount":3,"participants":["Luke Diamand","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"422554","messageId":"d9022ce8-2752-db75-f4b7-d5188c41bd90@diamand.org","threadId":"55534","inReplyTo":null,"subject":"Track changes across multiple branches, c.f. \"p4 interchanges\" ?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2021-04-21T09:54:04Z","receivedAt":"2021-04-21T09:54:01Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"We're moving over from Perforce to git.\n\nIn Perforce we can find out definitively if a given commit is on branchA \nbut not on branchB.\n\nIt doesn't use textual comparisons (c.f. \"git change-id\") but tracks \nwhich changes are on which branches.\n\nThis is invaluable for managing rapidly evolving sets of release branches.\n\nHow do I go about doing this in git?\n\n1. Cherry\n\n\"git cherry\" - but surely once the change gets sufficiently mangled by \nconflicts, won't it end up being \"lost\" ? That has certainly been my \nexperience in the past.\n\n2. Merge\n\nI could work on feature branches, and then \"git merge --no-ff\" the \nfeature branch - but when I do that I end up pulling all the intervening \nhistory over. e.g.\n\n\n - X - bugfix\n / \\\n A - B - C - D - E - M main\n \\\n R relbranch\n\nIf I do \"git merge bugfix\" onto relbranch, then as well as getting X, I \nalso get B and C, which I don't want.\n\n3. Always start from a merge base\n\nI could tell people that if they are making a bugfix that will need to \ngo onto multiple branches, that they need to start from some common \nmerge base, and then merge to the final target branches.\n\nThat's possible, but is quite a big change from the current workflow of \nworking on main and then \"p4 integrate\" individual changes over.\n\nAnd invariably people will start out thinking their change is not a \nbugfix, but a new feature, and then find that actually we need the new \nfeature on the release branch.\n\n4. Use gerrit change-ids\n\nWe could adopt gerrit change-ids. It feels like this is kind of a \nkludge, but perhaps it's the only thing that really works?\n\nIs there something better?\n\nThanks!\nLuke\n\n\n\n\n"},{"id":"422623","messageId":"xmqqpmynxxup.fsf@gitster.g","threadId":"55534","inReplyTo":"d9022ce8-2752-db75-f4b7-d5188c41bd90@diamand.org","subject":"Re: Track changes across multiple branches, c.f. \"p4 interchanges\" ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-21T19:05:02Z","receivedAt":"2021-04-21T19:05:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luke Diamand writes:\n\n> 2. Merge\n> ...\n> If I do \"git merge bugfix\" onto relbranch, then as well as getting X,\n> I also get B and C, which I don't want.\n\nThis won't work exactly for the reason why you want to do #3 below.\n\n> 3. Always start from a merge base\n>\n> I could tell people that if they are making a bugfix that will need to\n> go onto multiple branches, that they need to start from some common \n> merge base, and then merge to the final target branches.\n> ...\n> And invariably people will start out thinking their change is not a\n> bugfix, but a new feature, and then find that actually we need the new \n> feature on the release branch.\n>\n> 4. Use gerrit change-ids\n>\n> We could adopt gerrit change-ids. It feels like this is kind of a\n> kludge, but perhaps it's the only thing that really works?\n>\n> Is there something better?\n\nJust to throw another in for completeness (not claiming which one is\nbetter and which one is worse):\n\n5. Primarily use #3 to merge, but use \"cherry-pick -x\" when\n replaying a fix that was built on a wrong base, and tweak the\n procedure to find out \"is this fix already on branch X?\" to also\n pay attention to it.\n\nIt is no worse than #4, I would think, as both approaches would need\nto scan the commit log messages to find the commits that are not in\nthe ancestry chain that participated to the branch.\n\n"},{"id":"423045","messageId":"7985e148-8bde-4b5c-ea7d-eb5c9f13e61f@diamand.org","threadId":"55534","inReplyTo":"xmqqpmynxxup.fsf@gitster.g","subject":"Re: Track changes across multiple branches, c.f. \"p4 interchanges\" ?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2021-04-26T21:35:03Z","receivedAt":"2021-04-26T21:35:00Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"\n\nOn 21/04/2021 19:05, Junio C Hamano wrote:\n> Luke Diamand writes:\n> \n>> 2. Merge\n>> ...\n>> If I do \"git merge bugfix\" onto relbranch, then as well as getting X,\n>> I also get B and C, which I don't want.\n> \n> This won't work exactly for the reason why you want to do #3 below.\n> \n>> 3. Always start from a merge base\n>>\n>> I could tell people that if they are making a bugfix that will need to\n>> go onto multiple branches, that they need to start from some common\n>> merge base, and then merge to the final target branches.\n>> ...\n>> And invariably people will start out thinking their change is not a\n>> bugfix, but a new feature, and then find that actually we need the new\n>> feature on the release branch.\n>>\n>> 4. Use gerrit change-ids\n>>\n>> We could adopt gerrit change-ids. It feels like this is kind of a\n>> kludge, but perhaps it's the only thing that really works?\n>>\n>> Is there something better?\n> \n> Just to throw another in for completeness (not claiming which one is\n> better and which one is worse):\n> \n> 5. Primarily use #3 to merge, but use \"cherry-pick -x\" when\n> replaying a fix that was built on a wrong base, and tweak the\n> procedure to find out \"is this fix already on branch X?\" to also\n> pay attention to it.\n> \n> It is no worse than #4, I would think, as both approaches would need\n> to scan the commit log messages to find the commits that are not in\n> the ancestry chain that participated to the branch.\n\nWith the gerrit change-id I can enforce that every commit will always \nhave a change-id - either a brand new one, or one that's preserved from \nanother commit.\n\nIf I just rely on people to use \"git cherry-pick -x\" then they will \ncertainly forget, or do it twice, because people make mistakes.\n\n"}]}