A couple of messages accidentally went off-list, forwarding them back here with
Werner's agreement :-)
On 21/10/13 08:02, Werner LEMBERG wrote:
The other advantage is that the merge commit is "authored" by the
person with master commit access who approves the merge request.
So, you have in history not just who wrote what, but also who took
the decision to include it. That can be valuable.
Hmm. In case this is important, you have to GPG-sign patches,
possible since git version 1.7.9. I think that lilypond doesn't
belong into the category of programs where this is necessary.
Yes, GPG-signed patches can be used to track authorization, approval etc., but
as you say, it's overkill for something like Lilypond. I'm just talking instead
about having an easily visible record of "Who reviewed/approved this?".
It's surely a matter of taste, but personally on a large-ish project with lots
of contributors, I find the "only merge commits in the master branch" approach
to be quite useful as a way of keeping a clean overview of changes to the
codebase, with the option to drill deeper if necessary.
You might read
http://mikegerwitz.com/papers/git-horror-story.html
on this topic.
Thanks for that -- had not come across it before.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel