Thread (1 message) 1 message, 1 author, 2016-08-11

Re: [PATCH] Documentation tutorial.txt: Teach the reader about git commit -a -s

From: Junio C Hamano <hidden>
Date: 2016-08-11 20:21:51

"Paolo Ciarrocchi" [off-list ref] writes:
I think it's important to mention, in the collaboration section,
that is possible to use the -s option to add the Signed-off-by
line

Signed-off-by: Paolo Ciarrocchi <redacted>
S-O-B is a project convention that follows the patch acceptance
policy similar to the kernel, and I am a bit reluctant to tell
people to use -s before making it clear what the legal intent of
that line is.  And git tutorial is not the place to talk about
the patch acceptance policy of the git project.

So instead, my preference is to suggest people to use "commit
-s" in "Documentation/SubmittingPatches" section.  That _is_
about the git project, and I think it helps the users that the
same rule/tip applies to the kernel by making it clear that the
convention and legal intent of S-O-B were borrowed from them.

I am slightly disturbed by 
------------------------------------------------
(edit files)
+$ git commit -a (add -s to add Signed-off-by line at the end of the
commit message)
(repeat as necessary)
------------------------------------------------
this formatting.  The examples that begin with '$' are meant to
be "copy-me" examples, and we do "# comment" elsewhere for
exactly that reason.

If your MUA corrupts patches, then working it around by using
attachment is tolerated, but please do try to see if you can
make your MUA behave first.  Attachments are hard to comment on
inline.

If you need to do an attachment, please do not include the patch
twice.  That is a lot worse than having your patch only in the
attachment.  I need to detach only the attachment part, compare
it with what were discussed on the list based on the patch that
was in the non-attachment part of your message to make sure
there is no inconsistency between the two, and then apply the
one from the attachment separately.

Instead, make the first "text" part of the multipart to contain
the proposed commit log message, and make sure that the rest of
the message (if multipart, then mailinfo will unwrap them for me
and concatenate them together after the first '---' in the cover
text) does not have the same patch twice.

Your message has the first text part in "format=flawed", which
included a corrupted patch, and then the attachment contained a
full format-patch output.  As a result, taken as a whole the
message includes the patch twice (once corrupted and then
uncorrupted).  Please don't.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help