Notification mails for git repos

[Geert Janssens]

On 31-01-13 17:15, John Ralls wrote:
> 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.
Perhaps I do. That's why I'm discussing this topic here :)
>   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.
I believe this is in large part  because the common ancestor between 2.4 
and trunk is already too far down history. I explicitly said regularly 
merging into the development branch.

Isn't it so that git's merge starts to compare differences from the most 
recent common ancestor ? That would mean that if the bugfixes were 
merged into development frequently (in the extreme case for each bugfix 
commit) the merge conflicts would be no more complicated than you would 
encounter with cherry-picking.
>
> 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.
Sure, but I'm not convinced yet that that reason is our use case here. 
Suppose we depend on cherry picking for back- or forward-porting. How 
can it help us not to forget any back- or forward ports without having 
to go through all the commits manually to compare them between branches ?

Our current process (using the BP and AUDIT markers) has the same 
weaknesses IMO. There is no clear indication in the commit history of 
which commits were backported. We have BP/AUDIT as a visual reminder 
that backports should happen, but no easy way to check in retrospect if 
they actually happened.
>
>>> 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.
No, we're not set up for that. But I believe it should be one of our 
goals to get better test coverage. I know you have this on your agenda 
and I'm quite happy about it.

A couple of times I started looking into writing tests myself, but never 
managed to actually produce some due to lack of time and experience. 
Perhaps this is a good time to ask:
a. do you know of a good introduction to unit testing ?
b. is there some documentation on the unit testing framework used in 
gnucash ? How should a test be constructed ? Are there particular 
functions that should be used ? Things like that.

Geert