Notification mails for git repos

John Ralls jralls at ceridwen.us
Wed Jan 30 22:37:39 EST 2013


On Jan 30, 2013, at 9:27 AM, Yawar Amin <yawar.amin at gmail.com> wrote:

> Hi Geert,
> 
> On 2013-01-30, at 11:13, Geert Janssens <janssens-geert at telenet.be> wrote:
> 
>> [...]
>> Alternatively I played with the idea to just drop the whole BP trickery.
> 
> Right idea....
> 
>> Instead we could use a backport branch in git. Each dev that commits something to trunk/master that should also be backported, could cherry-pick this commit to the backport branch.
> 
> See below for another way....
> 
>> [...]
>> Any thoughts, bright ideas, suggestions ?
> 
> With a pure git solution, we can get rid of backporting and switch to daggy fixes (http://queue.acm.org/detail.cfm?id=1595636, section 'Daggy Fixes and Cherry-picking', near the end). Benefits: backporting will become simply merging; the dag will show us exactly where a fix was made and to which branches it was applied.
> 

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



More information about the gnucash-devel mailing list