Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Taylor Blau <me@ttaylorr.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 17:48:14 -0400
Message-ID: <20201020214814.GD75186@nand.local> (raw)
In-Reply-To: <20201020212820.GA1368742@ebb.org>

Hi Bradley,

On Tue, Oct 20, 2020 at 02:28:20PM -0700, Bradley M. Kuhn wrote:
> 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:

The conclusive answer is that you can do anything you want when the
patches are in 'seen', but when it is in 'next', things have solidified
and the series is not meant to be changed. The one exception to that
rule is immediately after a release, in which case 'next' is rewound
(and thus some topics can be ejected from next).

> 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 think the latter is really only talking about branches based on
'master' (of course, the same thing is true of branches based on any
branch, but it's uncommon to base topics off of 'seen').

The former is saying that 'seen' may change zero, one, or multiple times
during the lifetime of a topic. The latter says if you track upstream's
'master' and then 'git pull --rebase', 'git rebase' will tell you if
your patches are already applied upstream (in which case you can drop
them).

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

It couldn't hurt to add something to the effect of:

  Since 'seen' is a convenience branch that contains the current state
  of the in-flight topics, it is subject to be changed and rebuilt
  multiple times (c.f., link:howto/maintain-git) so the presence of your
  patches in 'seen' (but not 'next' or 'master') should not affect your
  workflow.

Thanks,
Taylor

  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 [this message]
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
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=20201020214814.GD75186@nand.local \
    --to=me@ttaylorr.com \
    --cc=bkuhn@sfconservancy.org \
    --cc=git@vger.kernel.org \
    /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