On Jan 30, 2013, at 8:06 PM, Yawar Amin <[email protected]> wrote:
> Hi John, > > On 2013-01-30 22:37, John Ralls wrote: >> [...] >> 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. > > Yes, that is a given. My fundamental point was that instead of the > backporting and cherry-picking trickery we can use git's own branching model > to support bugfixes on multiple series. And looking at the logs will make it > immediately obvious which bugfixes were applied where, instead of having to > manually interpret commit IDs. Well, manually interpreting commit IDs in git is futile, but changes in the backports branch still have to be cherry-picked into the actual release branches for them to fix anything, so what exactly is the point? Cherry-picks don't show the original branch in history. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
