[Geany-devel] Commit messages on merges

[Colomban Wendling]

Le 28/02/2012 06:59, Frank Lanitz a écrit :
> Am 27.02.2012 08:44, schrieb Lex Trotman:
>> [...]
>>>
>>> I guess if we can filter out merge commits and only show the real commit
>>> information it should be good?
>>>
>>> (See other message with individual commit messages)
>>
>> Yeah, IMO git gives us lots of un-needed merge messages, not much more
>> we can really say other than merged master into branch, so we will
>> have to filter them for human consumption in newsletters anyway.
> 
> It's not git. It's most likely githubs's webinterface which is causing
> the entries I'm not happy about. Using command line git merge -m "I just
> did some cool stuff" would be a bit better. Now git log e.g. looks like

I agree that the merge commits should be a bit informative on what they
do, but the branch name should be a good starting point.  In the two
examples below the branch name make me clearly think that those
"branches" (actually pull simply requests I guess) simply holds random
stuff that doesn't depend on each other.  I guess if Jiří made a single
PR it's more because he though having one per commit was overkill rather
than because these commits had strong relationship.

Maybe the "project_patches" one has some semantic, but I doubt "fixes"
does.

> commit 3bcd7fc40078efd601f0e9bed8efec971d505db2
> Merge: 3d4e8b4 5cc8a96
> Author: Matthew Brush <mbrush at codebrainz.ca>
> Date:   Sun Feb 26 21:04:50 2012 -0800
> 
>     Merge pull request #19 from techee/fixes
> 
>     Fixes
> 
> commit 3d4e8b41d419255ee1b0764fb60e45ea588bd800
> Merge: d7d5a6d ca9dca9
> Author: Matthew Brush <mbrush at codebrainz.ca>
> Date:   Sun Feb 26 20:50:01 2012 -0800
> 
>     Merge pull request #25 from techee/project_patches
> 
>     Project patches
> 
> 
>> The alternative is to always re-base before committing merged branches
>> to master, which is probably better since we don't care how the
>> developer got to the end point and all the commits and merges she made
>> on the way, we just care what the commit to master does.
> 
> No. This will remove most probably of e.g. additional contributors.

Rebasing doesn't lose authorship information, it just loses original
commits hierarchy.  Sometimes this hierarchy is useful (like join_lines
patches which makes a whole) and sometimes it is just useless stuff that
makes the history less readable (like Jiří's "fixes" branch where each
commit is a whole without relationship with the other).

IMO we should not record merges when there is only one single commit or
when the commits are unrelated (though the latter should probably be
less common) and rather rebase or cherry-pick the commits.

However, we must keep the merge when the commits are a whole thing not
to lose that information (when several commits are needed to implement a
single thing).


Regards,
Colomban

> Cheers,
> Frank