"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > Changes since v1: > > * Rebased onto master (no conflicts, so it is safe, and it is more robust > than basing the patches on seen which already contains v1 of these > patches). Thanks, I actually wanted to include it in 'maint', so I'll queue on the same base (no conflicts, so it is safe, and it will be in a maintenance release if we are going to issue one). > * Adjusted the quoting to match > https://lore.kernel.org/git/e250f1bb100aca94c914f1b2d38a3849c2566aea.1592909867.git.liu.denton@xxxxxxxxx/ I know I mentioned it and I think the patch to SubmittingPatches does improve by doing `seen` because it matches the way how the nearby `git pull --rebase` is quoted. But I am not sure about the patch to gitworkflows.txt, where the text around the new `seen` mention 'master' and 'next'. I think your v1 was more (locally) consistent. I am on the fence to the change to giteveryday.txt, where `pu` got changed to `seen`; your v1 had "(patches seen by the maintainer)" as an explanation after the `seen`. I guess it is inconsistent to explain only why `seen` is `seen` without doing the same for `next`, so I would say v2 is an improvement over v1. In short, > 1: dc6f971290 ! 1: 35e3dafd6a docs: adjust for the recent rename of `pu` to `seen` > @@ Documentation/SubmittingPatches: their trees themselves. > 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 pu if you rebase on top of > -+ tell you if your patch is merged in 'seen' if you rebase on top of > ++ tell you if your patch is merged in `seen` if you rebase on top of > master). Good. > * Read the Git mailing list, the maintainer regularly posts messages > @@ Documentation/giteveryday.txt: $ git push --follow-tags ko <13> > <2> see which branches haven't been merged into `master` yet. > Likewise for any other integration branches e.g. `maint`, `next` > -and `pu` (potential updates). > -+and `seen` (patches seen by the maintainer). > ++and `seen`. Probably good. > <3> read mails, save ones that are applicable, and save others > that are not quite ready (other mail readers are available). > <4> apply them, interactively, with your sign-offs. > @@ Documentation/gitworkflows.txt: As a given feature goes from experimental to sta > -* 'pu' (proposed updates) is an integration branch for things that are > - not quite ready for inclusion yet (see "Integration Branches" > - below). > -+* 'seen' (patches seen by the maintainer) is an integration branch for > ++* `seen` (patches seen by the maintainer) is an integration branch for Not---'seen' was more consistent relative to the surrounding text. Thanks.
