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 <hansunz...@gmail.com>
Sent: November 27, 2022 10:54 AM
To: emc-developers@lists.sourceforge.net <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 <bodge...@gmail.com>
Sent: November 23, 2022 4:59 PM
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: [Emc-developers] Merge Strategy
On Tue, 8 Nov 2022 at 21:38, Chris Morley <chrisinnana...@hotmail.com> 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
