On 31-01-13 20:40, John Ralls wrote:
On Jan 31, 2013, at 10:22 AM, Geert Janssens <[email protected]> wrote:
On 31-01-13 18:26, John Ralls wrote:
On Jan 31, 2013, at 8:52 AM, Yawar Amin <[email protected]> wrote:
Hi John,
On 2013-01-31, at 11:15, John Ralls <[email protected]> wrote:
[...]
I think that you guys have a misunderstanding about how merging works. Try
merging 2.4 back into trunk.
When I did just now, 4 files merged successfully, the rest have conflicts. One
might be able to do better by playing with the merge options. I'm not going to
spend the time.
Merging a commit doesn't just look at the files touched by that particular
commit, it looks at every difference between the trees of the source commit and
the target (i.e., the current branch).
Cherry-pick exists for a reason.
I think we have to look at this from the other end: 2.4 is not merging cleanly
into trunk precisely _because_ of all the cherry-picking/backporting that's
been going on.
If you create a new git branch, e.g. 2.6, from trunk, and don't allow any
backported patches on it, I'd say you'd have a much better chance of a clean
merge.
If you create a new git branch from trunk and don't make any changes (remember,
backports are the only allowed changes on a release branch), then of course it
will merge cleanly: It won't have any changes, so the merge will be a no-op.
Geert corrected me about when 2.4 was branched, so we can easily demonstrate
this using 2.4.3:
$ athena:/Users/john/gnucash> git merge 2.4.3
Already up-to-date!
Kinda misses the point about having a stable branch, though.
Regards,
John Ralls
I'm under the impression we are not talking about the same configuration. For me the
premise of this discussion was to have a stable branch and a development branch. Bugfixes
are done on the stable branch, new features or bug fixes too drastic for stable happen on
development. To get the bugfixes from stable to development the stable branch is
regularly merged into development. Regularly being the key here to avoid merges that
become too complicated. In this scenario not "backports" happen from
development to stable, but bugfixes still get forward-ported to development.
Perhaps some drawings may help. Consider this starting point:
- A - B - C (development)
\
----- D (stable)
A is the last common commit between stable and development. Development has
been going in for a while, resulting in commits B and C on that branch. Then a
bugfix commit D is created on stable (not on development).
Bugfixes should also go into development, so at this point the stable branch is
to be merged into development. First step of the merge: create a temporary
branch on stable (we want stable to remain an independent branch after the
merge:
- A - B - C (development)
\
----- D (stable, tmp-branch)
Then merge this tmp-branch into development, possibly fixing any merge
conflicts. These merge conflicts would have been there in the
backport/cherry-pick scenario as well, so nothing new.
- A - B - C - D' (development, tmp-branch)
\ /
----- D - (stable)
The tmp-branch is discarded now, it only served for the merging. More
development continues on development and at some point another bugfix lands on
stable:
- A - B - C - D' - E - F (development)
\ /
----- D ---------- G (stable)
Same dance. Setup temporary branch, merge it into trunk potentially resolving
conflicts. Given commit D is already merged, I assume that git will only take
the differences in commit G into account for the merge, resulting in this new
picture:
- A - B - C - D' - E - F - G' (development)
\ / /
----- D ---------- G - (stable)
It looks pretty much like the inverse of our current backport strategy with the
same merge conflict issues as cherry-picking. The big advantage in this process
is that the git history shows you in one glance which bugfixes are not merged
into development yet.
Note that refinement is possible by requiring separate branches for most
development, that then have to be merged into stable or development after
review. Kind of re-adds the AUDIT procedure that currently is no longer in use.
Possibly this process is flawed in other ways I'm missing. I'm happy to learn
about them.
This breaks down when B and C affect the same code that D does. Obviously you resolve
those conflicts in favor of the development branch when you merge D. No problem, right?
Well, you have to resolve them again for every subsequent merge. That snowballs into
"too hard" after a few dozen changes, as my merge of 2.4 into trunk
demonstrated.
Oh, boy, there's my wrong assumption. I assumed that after merging D
into B and C, git would no longer consider D's changes for the next merge.
If it is as you say, my proposed method would not work at all obviously.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
