On 31-01-13 04:37, John Ralls wrote:
Sorry, no. His central premise:
Let us return to the fold of Mercurial and Git. Since these tools offer the
ability to make a commit on top of any revision, thereby spawning a tiny
anonymous branch, a viable alternative to cherry-picking is as follows: use
bisect to identify the revision where a bug arose; check out that revision; fix
the bug; and commit the fix as a child of the revision that introduced the bug.
This new change can easily be merged into any branch that had the original bug,
without any sketchy cherry-picking antics required. It uses a revision-control
tool's normal merge and conflict-resolution machinery, so it is far more
reliable than cherry-picking (the implementation of which is almost always a
series of grotesque hacks).
is fundamentally flawed. The new change can *not* be cleanly merged into any
branch if the code that it affects has been changed since the commit that
introduced the bug. It's no different from any other cherry-pick.
So the extra work of bisecting to find the origin of the bug is wasted -- and
if, as he suggests earlier, that the bug was introduced years ago, the bisect
can take days, especially if it is a bug that isn't tractable to a simple test
allowing an automatic bisect, meaning most non-trivial bugs.
There's no way to escape the fact that if the code in one branch has diverged
substantially from that in another, porting code between the two can't be done
automatically. A competent programmer must do the work to understand the
differences and modify the patch accordingly.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
I certainly agree that his focus on merge being easier than cherry-pick
is misplaced. The advantage I do see in merging over cherry-picking is
that git's history would visually show which bugfixes went where. You go
to the bugfix and follow the branch paths from there.
With cherry-picking this link is only visible by reading commit logs. As
far as git itself is concerned, the original commit and the one
cherry-picked to another branch are unrelated.
So there is some value in a process that can rely on merging instead of
cherry-picking to keep track of commits on multiple branches.
That doesn't necessarily mean the whole daggy fix philosophy would be
required for this though. Other schemes could work as well, but daggy
fix is a good example to get us thinking in different directions.
As said in another mail already, this can only work once svn is
completely phased out of our process. Svn's branching and merging
facilities are too weak for such mechanisms.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
