On Thu, Oct 15, 2020 at 06:54:30PM -0700, Junio C Hamano wrote: > > > Documentation/git-commit.txt | 13 ++++++++----- > > > Documentation/merge-options.txt | 13 ++++++++----- > > > 2 files changed, 16 insertions(+), 10 deletions(-) > > > > Since the changes are exactly the same in the two files, maybe > > a preparatory patch that creates 'signoff.txt' and includes it > > in 'git-commit.txt' and 'merge-options.txt' would be a good idea ? > > I actually think we are OK with two duplicated and leave that for > later clean-up. The more important would be to polish the text into > a good enough state quickly. > > Another thing we should not forget is to update our SubmittingPatches > document. Since we are placing extra stress on that there is NO > inherent meaning in "sign off" and it is largely up to each project, > we should set a good example explaining what it means to THIS > project to sign your patches off, and SubmittingPatches is the > document to do so. Without such an update, I think the update > to these two files we see in this patch is incomplete. I agree we should be leading by example here. We do already say pretty clearly what signed-off-by means in the project: $ grep -A14 '\[\[sign-off]]' Documentation/SubmittingPatches [[sign-off]] === Certify your work by adding your "Signed-off-by: " line To improve tracking of who did what, we've borrowed the "sign-off" procedure from the Linux kernel project on patches that are being emailed around. Although core Git is a lot smaller project it is a good discipline to follow it. The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the below D-C-O: [[dco]] .Developer's Certificate of Origin 1.1 What should we change there? We could perhaps bring up signoffs earlier or more prominently. Or tie it in to the git-commit docs by saying explicitly: these are _our_ project rules for signoffs. -Peff
