Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Bradley M. Kuhn" <bkuhn@sfconservancy.org>
Cc: Taylor Blau <me@ttaylorr.com>, 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 15:06:05 -0700
Message-ID: <xmqq7drka6ya.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20201020212820.GA1368742@ebb.org> (Bradley M. Kuhn's message of "Tue, 20 Oct 2020 14:28:20 -0700")

"Bradley M. Kuhn" <bkuhn@sfconservancy.org> writes:

> 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:

Being 'seen' is an indication that it has been seen and does not
mean anything more than that.  It is appreciated that a topic in
such a state is improved by replacing.

> 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.

Yes.  Other people then can "git fetch" from me and follow the first
parent chain "git log --first-parent origin/master..origin/seen" to
find the tip of your topic, instead of finding your message in the
list archive and running "git am" themselves.

The original submitter/owner of the topic can also find the tip of
the topic _in_ my tree the same way as others and reset their branch
to what is queued in 'seen' if they wanted to keep minor fixes I
made based on review comments while applying the e-mailed patches.

Then they can further work on polishing the topic with the usual
means, e.g. using "rebase -i", and finally "format-patch" to send
out a new round.  Being or not being in 'seen' does not change the
workflow that much.

>>> `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).

This is talking about a fairly mature topic that has already been in
'next' and was on the course to graduate to 'master'.  The topic
would eventually be in 'master', and at that point "pull --rebase"
would notice that the patches are no longer needed (or were merged
in a different form).  But that does not apply to topics that are
not in 'master' yet.

Where the workflow changes is when the topic hits 'next'.  After
that, we request you to give incremental updates to refine what is
queued already.  

The reasoning behind this is simple and arbitrary.  It often is the
case that keeping mistakes in early iterations, and fixes to these
mistakes, recorded in history is not worth the attention of future
readers of "git log" who need to study the history, assuming that
trivial mistakes are caught early.  Once earlier rounds of review is
done and everybody is more or less happy, the topic gets merged to
'next', and after that point, a new issue that gets noticed and
fixed _are_ worth recording in history, because both the original
contributor and reviewers failed to catch such glitches.

> 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.

I thought your v3 did things perfectly.

Thanks.

  parent reply index

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
2020-10-20 21:48                               ` Taylor Blau
2020-10-20 22:06                               ` Junio C Hamano [this message]
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
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7drka6ya.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git