5 ms·
>> For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign th
by amazingman 9y ago
>> For example you can have a feature branch that has many small commits and one merge commit that joins feature branch with master and you just need to sign the merge commit to make sure all of these small commits are OK.
The above example still makes sense, even given your point about the mild absurdity of the idea that the entire repo is implicitly trusted.
- stouset 9y agoWhile this is technically true, what's the point in making the whole thing more complicated? Say you relax the restrictions such that only the first parent of every commit must be signed. While this might make sense for a small branch edited by one person, what if it was a long-lived branch modified by multiple people? The only case I can see for such a system is if you're doing a pull-request based workflow where your code review tool (GHE, Bitbucket, whatever) is the only tool capable of updating `master` and produces signed merge commits whenever a branch passes code review. Then you can at least (in theory) attest that all commits to master have been reviewed. But if not that, and people are signing their commits to master anyway (which you can automate in your `~/.gitconfig`, why allow exemptions to commits on branches?