|
From: | Joseph Rushton Wakeling |
Subject: | Re: improving our workflow with better tools - let's test things. |
Date: | Mon, 21 Oct 2013 09:38:11 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |