Notification mails for git repos
jralls at ceridwen.us
Wed Jan 30 23:32:41 EST 2013
On Jan 30, 2013, at 8:06 PM, Yawar Amin <yawar.amin at gmail.com> 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.
More information about the gnucash-devel