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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Paolo Ciarrocchi" <paolo.ciarrocchi@xxxxxxxxx> 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 <paolo.ciarrocchi@xxxxxxxxx>

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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]