From: "Bradley M. Kuhn" <bkuhn@sfconservancy.org>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by
Date: Tue, 20 Oct 2020 14:28:20 -0700 [thread overview]
Message-ID: <20201020212820.GA1368742@ebb.org> (raw)
In-Reply-To: <20201020023407.GB54484@nand.local>
Taylor Blau wrote:
> Thanks; I think some of our emails crossed over one another, but this
> version looks good to me.
Yes, I was preparing the patch when you wrote that you disagreed with Junio
and preferred the ":".
FWIW, I left the ":" anywhere headers were being discussed and those headers
were described with ":"s on them. I only changed places where
"Signed-off-by:" stood alone.
Before my v3 patchset, usage was inconsistent about (roughly half/half), so
the decision is mostly a coin toss. I didn't have a strong opinion when I
was first writing the v3 patchset, but having thought about it overnight, I
now think leaving the ":" *out* is better because a reader new to Git is more
likely to think a ":" is punctuation, rather than being part of a moniker.
Thus, IMO, leaving out the ":" in most cases probably improves readability.
The remainder of this email is purely an edification question that may help
serve to improve Documentation/SubmittingPatches:
> I'd be happy to discard what's currently in seen (integrated as 1b98087e0f
> (Merge branch 'bk/sob-dco' into jch, 2020-10-19 at the time of writing) in
> favor of what's here.
I wasn't sure what I should be doing with the patch set once it was already
in 'seen'. The only two references in SubmittingPatches I could find were:
From Documentation/SubmittingPatches:
>> In any time between the (2)-(3) cycle, the maintainer may pick it up from
>> the list and queue it to `seen`, in order to make it easier for people
>> play with it without having to pick up and apply the patch to their trees
>> themselves.
and
>> `git pull --rebase` will automatically skip already-applied patches, and
>> will let you know. This works only if you rebase on top of the branch in
>> which your patch has been merged (i.e. it will not tell you if your patch
>> is merged in `seen` if you rebase on top of master).
The former hints that you *shouldn't* change the workflow if some of your
patchset is in `seen`, and the latter hints that maybe you should, but
neither section tells you what to do differently, if anything, once your
patches are in `seen`.
I'm curious to know if I went wrong somewhere and the workflow and would be
glad to propose another patch to improve SubmittingPatches with a section of
what to do when patches show up in `seen`, but since I'm a n00b (at least as
an upstream Git contributor :), I'd need to know how to DTRT in this case to
do that.
--
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
next prev parent reply other threads:[~2020-10-20 21:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 21:59 [PATCH 0/1] Clarify and expand description of --signoff Bradley M. Kuhn
2020-10-15 21:59 ` [PATCH 1/1] Documentation: " Bradley M. Kuhn
2020-10-16 0:46 ` Jeff King
2020-10-18 15:13 ` Theodore Y. Ts'o
2020-10-16 1:49 ` [PATCH 0/1] " Philippe Blain
2020-10-16 1:54 ` Junio C Hamano
2020-10-16 1:59 ` Jeff King
2020-10-16 2:30 ` Junio C Hamano
2020-10-16 19:53 ` Junio C Hamano
2020-10-16 20:11 ` Jeff King
2020-10-17 3:00 ` Bradley M. Kuhn
2020-10-18 19:08 ` Junio C Hamano
2020-10-19 15:53 ` Theodore Y. Ts'o
2020-10-19 18:26 ` Junio C Hamano
2020-10-19 21:25 ` [PATCH v2 0/3] clarify and expand description of --signoff & related fixes Bradley M. Kuhn
2020-10-19 21:25 ` [PATCH v2 1/3] Documentation: clarify and expand description of --signoff Bradley M. Kuhn
2020-10-19 21:25 ` [PATCH v2 2/3] Documentation: stylistically normalize references to Signed-off-by: Bradley M. Kuhn
2020-10-19 22:02 ` Taylor Blau
2020-10-19 22:17 ` Junio C Hamano
2020-10-20 2:31 ` Taylor Blau
2020-10-20 1:03 ` [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by Bradley M. Kuhn
2020-10-20 1:03 ` [PATCH v3 1/4] doc: preparatory clean-up of description on the sign-off option Bradley M. Kuhn
2020-10-20 1:03 ` [PATCH v3 2/4] Documentation: clarify and expand description of --signoff Bradley M. Kuhn
2020-10-20 21:44 ` Bradley M. Kuhn
2020-10-20 21:48 ` Taylor Blau
2020-10-20 1:03 ` [PATCH v3 3/4] SubmittingPatches: clarify DCO is our --signoff rule Bradley M. Kuhn
2020-10-20 1:03 ` [PATCH v3 4/4] Documentation: stylistically normalize references to Signed-off-by: Bradley M. Kuhn
2020-10-20 18:52 ` Junio C Hamano
2020-10-20 21:33 ` Bradley M. Kuhn
2020-10-20 2:34 ` [PATCH v3 0/4] clarify meaning of --signoff & related doc improvements in describing Signed-off-by Taylor Blau
2020-10-20 21:28 ` Bradley M. Kuhn [this message]
2020-10-20 21:48 ` Taylor Blau
2020-10-20 22:06 ` Junio C Hamano
2020-10-20 23:02 ` Bradley M. Kuhn
2020-10-19 21:25 ` [PATCH v2 3/3] SubmittingPatches: clarify DCO is our --signoff rule Bradley M. Kuhn
-- strict thread matches above, loose matches on Subject: below --
2020-10-18 19:49 [PATCH v2 0/3] Claryfing the meaning of the sign-off Junio C Hamano
2020-10-18 19:49 ` [PATCH v2 1/3] doc: preparatory clean-up of description on the sign-off option Junio C Hamano
2020-10-18 19:49 ` [PATCH v2 2/3] Documentation: clarify and expand description of --signoff Junio C Hamano
2020-10-18 19:49 ` [PATCH v2 3/3] SubmittingPatches: clarify DCO is our --signoff rule Junio C Hamano
2020-10-18 23:31 ` [PATCH v2 0/3] Claryfing the meaning of the sign-off Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201020212820.GA1368742@ebb.org \
--to=bkuhn@sfconservancy.org \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).