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.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
