Re: [PATCH v2 0/3] Accommodate for pu having been renamed to seen

[Junio C Hamano <gitster@pobox.com>]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
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@gmail.com/

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.