On Jan 30, 2013, at 9:27 AM, Yawar Amin <[email protected]> wrote:
> Hi Geert, > > On 2013-01-30, at 11:13, Geert Janssens <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
