Notification mails for git repos

John Ralls jralls at ceridwen.us
Thu Jan 31 11:15:56 EST 2013


On Jan 31, 2013, at 7:04 AM, Derek Atkins <warlord at MIT.EDU> wrote:

> Geert Janssens <janssens-geert at telenet.be> writes:
> 
> [snip]
>> Daggy fixing is probably not the only useful scheme though. I could
>> also imagine something like this to work:
>> - all bugfixes and only bugfixes happen on the 2.4 branch
>> - the 2.4 branch regularly gets merged into the development branch, so
>> all bugfixes also will end up in future releases
>> This concept is no longer back-porting, but
>> forward-porting. Advantage: all bugfixes eventually end up in the
>> active trees and git branches show the history, no need for BP->AUDIT
>> 
>> Note that neither daggy fixing nor forward porting are possible as
>> long as we're tied to svn. So this discussion is on future process,
>> not practical next steps yet.
> 
> Techncally we could do the "all bugfixes go into release; frequently
> merge release back into trunk" method.  The downside is that larger
> "fixes" dont get tested as much before going into the release.
> 
I think that you guys have a misunderstanding about how merging works. Try merging 2.4 back into trunk.
When I did just now, 4 files merged successfully, the rest have conflicts. One might be able to do better by playing with the merge options. I'm not going to spend the time.

Merging a commit doesn't just look at the files touched by that particular commit, it looks at every difference between the trees of the source commit and the target (i.e., the current branch).

Cherry-pick exists for a reason.

>> How can we in the future improve our process to something in which the
>> history clearly reflects what actually happened, in which no work is
>> lost (by forgetting to backport) and without too much overhead.
> 
> And also test/review changes before they go into the release branch?

The generally accepted best practice for that is to require 100% test coverage and to require that all tests (including a new one that covers the current change) pass. It doesn't seem likely that we would adopt that practice.

Regards,
John Ralls





More information about the gnucash-devel mailing list