Re: [Emc-developers] Merge Strategy
Can you explain why merging up is better then cherry-picking or separate commits? Merge strategy should not change based on what should or should not be moved forward. The strategy must be the same. Chris From: Steffen Möller Sent: November 28, 2022 1:04 AM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy IMHO we should continue with the merge-up and start thinking again when there is a change to 2.9 that should not be forwarded. Best, Steffen > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Well we will never agree on anything different if we never discuss it. > How about throwing out an opinion here? > > Chris > > From: Hans Unzner > Sent: November 27, 2022 10:54 AM > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Merge Strategy > > I agree that we should stick to "merge up" until we reach an agreement > to change this. > > Hans > > Am 23.11.22 um 22:42 schrieb Chris Morley: > > Ya it's always been hard to consistently get answers in our project. > > It just seems the nature of our group. > > Thanks for continuing to try. > > > > Currently strategy is to merge up, though you can cherry-pick up too, as a > > merge later should understand this. > > But we rarely do anything with an older-then-current-release (I realize > > that 2.8 is still sorta current) > > > > On the absence of an agreement, I am merging up 2.9 to master to keep in > > sync. > > > > Chris > > > > From: andy pugh > > Sent: November 23, 2022 4:59 PM > > To: EMC developers > > Subject: [Emc-developers] Merge Strategy > > > > On Tue, 8 Nov 2022 at 21:38, Chris Morley > > wrote: > >> I wonder if we might discuss a different merging strategy for 2 9/master. > >> This would be relative to work being done in 2.9 for release. > >> > >> I suggest we don't merge up any more. > >> Cherry pick or a separate commit makes more sense to me. > >> > > Well, the discussion seems to have resulted in nothing happening, and > > some things in 2,8 that probably do belong in 2.9 and master. > > > > So what _is_ the current policy? > > > > > > -- > > atp > > "A motorcycle is a bicycle with a pandemonium attachment and is > > designed for the especial use of mechanical geniuses, daredevils and > > lunatics." > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
I still think merging upwards is the best way to do this. The main advantage is that git keeps track of what commits need to be propagated to the newer branch, so we'll never leave behind any bugfix commits in older stable branches. This avoids the terrible situation where we fix a bug in the stable branch, but the bug is "reintroduced" in the development branch because the bugfix commit never made it in to the newer branch. That said, I *am* sympathetic to the concern that if part of the software has evolved significantly between the stable branch and the development branch, and that part of the software got a bugfix, then the merge may have significant conflicts... So let me be specific, and compare the two situations, so we have a common place to discuss from. # Scenario 1 In this scenario the old stable branch (2.8) has several new commits: some that add a new driver, then a bugfix in old code, then some that add another new driver. The new branch (2.9) has lots of changes, but nothing that conflicts with the new stuff in 2.8. "Merging up" looks like this: $ git checkout 2.9 $ git merge origin/2.8 There are no conflicts so the merge is automatic. "Cherry-pick" looks like this: $ git checkout 2.9 # identify the list of commits needed, and cherry-pick each one Identifying the list of commits needed is a manual, error-prone process. Git doesn't provide much help here - you have to walk backwards through history in 2.8, and for each commit you have to guess if it has been already cherry-picked into 2.9 by searching for it in the 2.9 commit history. The only thing you have to go on is the commit message - if they're the same, then the 2.9 commit was probably cherry-picked from 2.8 (unless it was cherry-picked the other way, or reimplemented independently). Once you find a commit in 2.8 that's already in 2.9, then you may assume that every 2.8 commit *after* that one is new and should be cherry-picked into 2.9. You cherry-pick all the commits starting at that first new one and ending at the tip of 2.8, in order, into 2.9. In the current scenario there are no conflicts, so this process goes smoothly. But even in this easy scenario, this is a lot of error-prone manual labor. # Scenario 2 This is just like Scenario 1, except the bugfix in the old code *does* conflict with changes in 2.9. "Merging up" looks like this: $ git checkout 2.9 $ git merge origin/2.8 The merge detects the conflict and stops halfway through. You have a choice here: if it's a simple conflict you can resolve it yourself and finish the merge, or if it's too complicated you can `git merge --abort` and punt it to someone else. If you choose to punt, you have the option to do just the easy first part of the merge (remember, in this scenario 2.8 has a new driver, then a conflicting bugfix, then another new driver). So you would run `git log origin/2.8 ^origin/2.9` to see the log of just the not-yet-propagated new commits that are in 2.8. You'd identify the commit that finishes the first driver add, and `git merge` that commit into 2.9. (There will be no conflicts, according to this scenario.) Then email the folks who know more about the conflict and ask them to merge their bugfix into 2.9. "Cherry-pick" looks like this: Actually it looks just like Scenario 1 (including all the manual searching and guessing), except the cherry-pick of the bugfix will conflict, and at that point you fix it or punt just like in the "merging up" case. So that's my thinking. I hope this shows why i think merging up is better than cherry-picking. -- Sebastian Kuzminsky On 11/27/22 11:11, Chris Morley wrote: Well we will never agree on anything different if we never discuss it. How about throwing out an opinion here? Chris From: Hans Unzner Sent: November 27, 2022 10:54 AM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy I agree that we should stick to "merge up" until we reach an agreement to change this. Hans Am 23.11.22 um 22:42 schrieb Chris Morley: Ya it's always been hard to consistently get answers in our project. It just seems the nature of our group. Thanks for continuing to try. Currently strategy is to merge up, though you can cherry-pick up too, as a merge later should understand this. But we rarely do anything with an older-then-current-release (I realize that 2.8 is still sorta current) On the absence of an agreement, I am merging up 2.9 to master to keep in sync. Chris From: andy pugh Sent: November 23, 2022 4:59 PM To: EMC developers Subject: [Emc-developers] Merge Strategy On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: I wonder if we might discuss a different merging strategy for 2 9/master. This would be relative to work being done in 2.9 for release. I suggest we don't merge up any more. Cherry pick or a separate commit makes more sense
Re: [Emc-developers] Merge Strategy
Well we will never agree on anything different if we never discuss it. How about throwing out an opinion here? Chris From: Hans Unzner Sent: November 27, 2022 10:54 AM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy I agree that we should stick to "merge up" until we reach an agreement to change this. Hans Am 23.11.22 um 22:42 schrieb Chris Morley: > Ya it's always been hard to consistently get answers in our project. > It just seems the nature of our group. > Thanks for continuing to try. > > Currently strategy is to merge up, though you can cherry-pick up too, as a > merge later should understand this. > But we rarely do anything with an older-then-current-release (I realize that > 2.8 is still sorta current) > > On the absence of an agreement, I am merging up 2.9 to master to keep in sync. > > Chris > > From: andy pugh > Sent: November 23, 2022 4:59 PM > To: EMC developers > Subject: [Emc-developers] Merge Strategy > > On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: >> I wonder if we might discuss a different merging strategy for 2 9/master. >> This would be relative to work being done in 2.9 for release. >> >> I suggest we don't merge up any more. >> Cherry pick or a separate commit makes more sense to me. >> > Well, the discussion seems to have resulted in nothing happening, and > some things in 2,8 that probably do belong in 2.9 and master. > > So what _is_ the current policy? > > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
IMHO we should continue with the merge-up and start thinking again when there is a change to 2.9 that should not be forwarded. Best, Steffen > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Well we will never agree on anything different if we never discuss it. > How about throwing out an opinion here? > > Chris > > From: Hans Unzner > Sent: November 27, 2022 10:54 AM > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Merge Strategy > > I agree that we should stick to "merge up" until we reach an agreement > to change this. > > Hans > > Am 23.11.22 um 22:42 schrieb Chris Morley: > > Ya it's always been hard to consistently get answers in our project. > > It just seems the nature of our group. > > Thanks for continuing to try. > > > > Currently strategy is to merge up, though you can cherry-pick up too, as a > > merge later should understand this. > > But we rarely do anything with an older-then-current-release (I realize > > that 2.8 is still sorta current) > > > > On the absence of an agreement, I am merging up 2.9 to master to keep in > > sync. > > > > Chris > > > > From: andy pugh > > Sent: November 23, 2022 4:59 PM > > To: EMC developers > > Subject: [Emc-developers] Merge Strategy > > > > On Tue, 8 Nov 2022 at 21:38, Chris Morley > > wrote: > >> I wonder if we might discuss a different merging strategy for 2 9/master. > >> This would be relative to work being done in 2.9 for release. > >> > >> I suggest we don't merge up any more. > >> Cherry pick or a separate commit makes more sense to me. > >> > > Well, the discussion seems to have resulted in nothing happening, and > > some things in 2,8 that probably do belong in 2.9 and master. > > > > So what _is_ the current policy? > > > > > > -- > > atp > > "A motorcycle is a bicycle with a pandemonium attachment and is > > designed for the especial use of mechanical geniuses, daredevils and > > lunatics." > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
I agree that we should stick to "merge up" until we reach an agreement to change this. Hans Am 23.11.22 um 22:42 schrieb Chris Morley: Ya it's always been hard to consistently get answers in our project. It just seems the nature of our group. Thanks for continuing to try. Currently strategy is to merge up, though you can cherry-pick up too, as a merge later should understand this. But we rarely do anything with an older-then-current-release (I realize that 2.8 is still sorta current) On the absence of an agreement, I am merging up 2.9 to master to keep in sync. Chris From: andy pugh Sent: November 23, 2022 4:59 PM To: EMC developers Subject: [Emc-developers] Merge Strategy On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: I wonder if we might discuss a different merging strategy for 2 9/master. This would be relative to work being done in 2.9 for release. I suggest we don't merge up any more. Cherry pick or a separate commit makes more sense to me. Well, the discussion seems to have resulted in nothing happening, and some things in 2,8 that probably do belong in 2.9 and master. So what _is_ the current policy? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
