Notification mails for git repos

[Geert Janssens]

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
> gnucash-devel at gnucash.org
> 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