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. > 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. See my response to Mike Evans on bisect. > 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. True. But, as I say above, we can still have git track the relationship between the bugfix patches instead of doing it manually. Once svn is out of the picture, it's really upto each developer how they want to do backporting/daggy fixes. I for one am looking forward to trying it out on gnucash-docs. Regards, Yawar
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
