On 01-02-13 15:54, John Ralls wrote:
(Keeping the branch image for reference)
A - B - C - E - F - G - I - (trunk)
\ / /
--- D ------- H ----- (stable)
E and I are merge branches; E has both C and D as parents and able to generate
diffs to each of them, and I has both G and H as parents.
The problem I can see is when the A->D changes and the A->B->C changes
conflict, the A->B->C changes get accepted into D', AND the D->G
changes also affect the same code, so that delta can't be cleanly
applied to F to get G'.
Restating with the new notation, the A-B-C changes are incorporated into E AND
if the F-G changes also affect that code then H won't apply cleanly to get I.
This might actually be OK too, because git can still track the history back to
D on both legs of the merge and so may be able to limit the conflicts.
This issue is exactly the same between merging or cherry-picking, so choosing a merge
strategy over a cherry-pick strategy for our future process won't make this harder. In
both cases, the longer the two branches are diverged the more chance there will be for a
merge conflict when a certain commit is to be "copied" from one branch to
another.
Um, no, a cherry-pick has only one parent. See for example [1] which I cherry
picked from [2]. If D is cherry-picked into E then the conflicts *will* have to
be merged again at H. That was Yawar's point about the conflicts in trying to
merge 2.4 into trunk: Because all of the cherry-picks carry no history with
them (and svn would have eaten it anyway if we'd tried to merge, it has no
concept of multi-parent commits), git had to go back to the branch point and
couldn't recognize any common commits since.
Ok, I think we're visualising different scenarios here. I was comparing
a scenario of only cherry-picks (as we do now) against a scenario with
only merging (only possible in pure git). Your counter example assumes a
mixture of both: D is cherry picked, H is merged.
And even then whether or not you'd have to resolve the merge conflict a
second time also depends on what conflict resolution you chose the first
time.
I have added some experiments to my testing trees for additional
scenarios that were revealing to me.
My final conclusion would be (and your counter example nicely
illustrates this): in a pure git environment, cherry-picking has the
potential to create more merge conflicts than a properly executed merge
strategy, exactly because cherry-picking doesn't have the same rich
history available to make smart conflict resolution decisions.
Let me also note that sometimes cherry-picking may be the only option
(for example if you accidentally added a commit to the wrong branch, the
branch that is usually the target of merges, not the source). In that
case history can be restored by performing a merge immediately after the
cherry-pick operation from the branch that received the cherry-picked
commit to the branch that commit was originally wrongly committed.
By the way, John, you refer to commits you pushed to the glib git
repository. What policy is used by the glib developers to handle
multiple maintained versions ?
One more note on that: E may very well end up looking nothing like D because
B-C may have been enough of a change that a different approach is required, but
it's still necessary for it to be a multi-parent commit.
Absolutely. The extreme case being if commit D is not even wanted on the trunk
branch (like a product version number increase for example). It would still
have to be merged. You could choose to do it on commit D, resulting in an empty
commit with two parents, or you can wait for commit H, and make sure the
changes from commit D are reverted during the later merge.
For developers interested in the experiment, you can clone my testing
repository on github (https://github.com/gjanssens/testing.git) and look at the
development and stable branches.
For those unfamiliar with Github, the visualization is at
https://github.com/gjanssens/testing/network
Heh, that would include me. I didn't know this...
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
