From: Junio C Hamano <email@example.com> To: "Bradley M. Kuhn" <firstname.lastname@example.org> Cc: Taylor Blau <email@example.com>, firstname.lastname@example.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: <email@example.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" <firstname.lastname@example.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.
next prev 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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 \ firstname.lastname@example.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