Am 28.11.22 um 02:44 schrieb Sebastian Kuzminsky:
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.
A problem I see here is if the person who introduced this change doesn't
have push permissions to the repository to resolve the merge conflict by
himself.
What is the best solution to resolve it in this case?
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
