Skip to content

Accommodate for pu having been renamed to seen #668

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Accommodate for pu having been renamed to seen #668

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
13e03e0
docs: adjust for the recent rename of `pu` to `seen`
dscho Jun 23, 2020
13f3501
docs: adjust the technical overview for the rename `pu` -> `seen`
dscho Jun 23, 2020
e38ade2
tests: reference `seen` wherever `pu` was referenced
dscho Jun 23, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions Documentation/MyFirstContribution.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1179,8 +1179,8 @@ look at the section below this one for some context.)
[[after-approval]]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Đoàn Trần Công Danh wrote (reply to this):

Hi Dscho,

On 2020-06-23 15:04:13+0000, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
> index 0a5c8b7d493..492e573856f 100644
> --- a/Documentation/git-ls-remote.txt
> +++ b/Documentation/git-ls-remote.txt
> @@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
>  7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
>  c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
>  0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
> +$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc

rc is not with us anymore.

Should we replace it with next, too?

>  5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
> -c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
> +c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/seen
>  $ git remote add korg http://www.kernel.org/pub/scm/git/git.git
>  $ git ls-remote --tags korg v\*
>  d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99

-- 
Danh

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

Đoàn Trần Công Danh  <congdanhqx@gmail.com> writes:

> Hi Dscho,
>
> On 2020-06-23 15:04:13+0000, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
>> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
>> index 0a5c8b7d493..492e573856f 100644
>> --- a/Documentation/git-ls-remote.txt
>> +++ b/Documentation/git-ls-remote.txt
>> @@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
>>  7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
>>  c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
>>  0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
>> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
>> +$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
>
> rc is not with us anymore.
>
> Should we replace it with next, too?

I do not think so.  I think we never had 'rc'.

I think what the above example is demonstrating is this.

    SYNOPSIS calls the last command line arguments <refs>; they are
    actually mere patterns (which is how these command line
    arguments are described in the documentation).  It is *not* an
    error if no refs match a particular pattern.

And because we have no refs that match the pattern "rc", we only see
"master" and "pu" (now "seen") from the command.

I see a couple of possible improvements here:

 - The "<refs>...::" documentation should explain what kind of
   pattern match is performed here.  I recall these originally were
   just tail matches, but the rule might have been made more
   flexible over time.

 - The example should first explain the setting.  The first sample
   depends on the current (./.) repository having these tags or it
   would not work (showing the sample upfront and explaining the
   outcome shown in the sample would work well in this case,
   e.g. "we can see that in the current repository, there are tags
   X, Y and Z").  The second one at least needs to say two things:
   the sample repository does not have a branch called 'rc' and that
   is why it is not shown, and it is not an error for patterns to
   produce no match.

Thanks.

>
>>  5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
>> -c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
>> +c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/seen
>>  $ git remote add korg http://www.kernel.org/pub/scm/git/git.git
>>  $ git ls-remote --tags korg v\*
>>  d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1867953520-1592947936=:54
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Junio & Danh,

On Tue, 23 Jun 2020, Junio C Hamano wrote:

> =C4=90o=C3=A0n Tr=E1=BA=A7n C=C3=B4ng Danh  <congdanhqx@gmail.com> write=
s:
>
> > On 2020-06-23 15:04:13+0000, Johannes Schindelin via GitGitGadget <git=
gitgadget@gmail.com> wrote:
> >> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-r=
emote.txt
> >> index 0a5c8b7d493..492e573856f 100644
> >> --- a/Documentation/git-ls-remote.txt
> >> +++ b/Documentation/git-ls-remote.txt
> >> @@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tag=
s/v0.99.1
> >>  7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
> >>  c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
> >>  0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
> >> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu =
rc
> >> +$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master see=
n rc
> >
> > rc is not with us anymore.
> >
> > Should we replace it with next, too?
>
> I do not think so.  I think we never had 'rc'.

Indeed, and the context given in the patch demonstrates that no `rc` is
shown, so I assumed the same things as Junio explained here:

> I think what the above example is demonstrating is this.
>
>     SYNOPSIS calls the last command line arguments <refs>; they are
>     actually mere patterns (which is how these command line
>     arguments are described in the documentation).  It is *not* an
>     error if no refs match a particular pattern.
>
> And because we have no refs that match the pattern "rc", we only see
> "master" and "pu" (now "seen") from the command.

Precisely.

> I see a couple of possible improvements here:
>
>  - The "<refs>...::" documentation should explain what kind of
>    pattern match is performed here.  I recall these originally were
>    just tail matches, but the rule might have been made more
>    flexible over time.
>
>  - The example should first explain the setting.  The first sample
>    depends on the current (./.) repository having these tags or it
>    would not work (showing the sample upfront and explaining the
>    outcome shown in the sample would work well in this case,
>    e.g. "we can see that in the current repository, there are tags
>    X, Y and Z").  The second one at least needs to say two things:
>    the sample repository does not have a branch called 'rc' and that
>    is why it is not shown, and it is not an error for patterns to
>    produce no match.

Those sound like wonderful #leftoverbits to me.

Thank you,
Dscho

>
> Thanks.
>
> >
> >>  5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
> >> -c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
> >> +c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/seen
> >>  $ git remote add korg http://www.kernel.org/pub/scm/git/git.git
> >>  $ git ls-remote --tags korg v\*
> >>  d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99
>

--8323328-1867953520-1592947936=:54--

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Đoàn Trần Công Danh wrote (reply to this):

On 2020-06-23 12:31:45-0700, Junio C Hamano <gitster@pobox.com> wrote:
> Đoàn Trần Công Danh  <congdanhqx@gmail.com> writes:
> > On 2020-06-23 15:04:13+0000, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
> >> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
> >> index 0a5c8b7d493..492e573856f 100644
> >> --- a/Documentation/git-ls-remote.txt
> >> +++ b/Documentation/git-ls-remote.txt
> >> @@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
> >>  7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
> >>  c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
> >>  0918385dbd9656cab0d1d81ba7453d49bbc16250	refs/tags/junio-gpg-pub
> >> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
> >> +$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
> >
> > rc is not with us anymore.
> >
> > Should we replace it with next, too?
> 
> I do not think so.  I think we never had 'rc'.

You're right.
Actually, I didn't read the context after the diff but went to
215a7ad1ef (Big tool rename., 2005-09-07) instead.

In that tree, there's a line for refs/heads/rc:

	b1d096f2926c4e37c9c0b6a7bf2119bedaa277cb        refs/heads/rc

Not sure why it was there in the past but it's fixed in
6077d36299 (ls-remote doc: fix example invocation on git.git,
2013-06-22)


> I think what the above example is demonstrating is this.
> 
>     SYNOPSIS calls the last command line arguments <refs>; they are
>     actually mere patterns (which is how these command line
>     arguments are described in the documentation).  It is *not* an
>     error if no refs match a particular pattern.
> 
> And because we have no refs that match the pattern "rc", we only see
> "master" and "pu" (now "seen") from the command.
> 
> I see a couple of possible improvements here:
> 
>  - The "<refs>...::" documentation should explain what kind of
>    pattern match is performed here.  I recall these originally were
>    just tail matches, but the rule might have been made more
>    flexible over time.
> 
>  - The example should first explain the setting.  The first sample
>    depends on the current (./.) repository having these tags or it
>    would not work (showing the sample upfront and explaining the
>    outcome shown in the sample would work well in this case,
>    e.g. "we can see that in the current repository, there are tags
>    X, Y and Z").  The second one at least needs to say two things:
>    the sample repository does not have a branch called 'rc' and that
>    is why it is not shown, and it is not an error for patterns to
>    produce no match.

I guess this is a leftover from 6077d36299 (ls-remote doc: fix example
invocation on git.git, 2013-06-22), if this was documented together
with said commit, it'll be less confusing.

> 
> Thanks.
> 
> >
> >>  5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
> >> -c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
> >> +c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/seen
> >>  $ git remote add korg http://www.kernel.org/pub/scm/git/git.git
> >>  $ git ls-remote --tags korg v\*
> >>  d6602ec5194c87b0fc87103ca4d67251c76f233a	refs/tags/v0.99

-- 
Danh

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Denton Liu wrote (reply to this):

Hi Dscho,

On Wed, Jun 24, 2020 at 02:48:38PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
> index abc0dc6bc7..0965b60884 100644
> --- a/Documentation/gitworkflows.txt
> +++ b/Documentation/gitworkflows.txt
> @@ -85,15 +85,15 @@ As a given feature goes from experimental to stable, it also
>  
>  There is a fourth official branch that is used slightly differently:
>  
> -* '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
> +  things that are not quite ready for inclusion yet (see "Integration
> +  Branches" below).

Tiny nit: we should use sq instead of backticks to match the style of
the rest of the document.

-Denton

=== After Review Approval

The Git project has four integration branches: `pu`, `next`, `master`, and
`maint`. Your change will be placed into `pu` fairly early on by the maintainer
The Git project has four integration branches: `seen`, `next`, `master`, and
`maint`. Your change will be placed into `seen` fairly early on by the maintainer
while it is still in the review process; from there, when it is ready for wider
testing, it will be merged into `next`. Plenty of early testers use `next` and
may report issues. Eventually, changes in `next` will make it to `master`,
Expand Down
10 changes: 5 additions & 5 deletions Documentation/SubmittingPatches
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ change is relevant to.
base your work on the tip of the topic.

* A new feature should be based on `master` in general. If the new
feature depends on a topic that is in `pu`, but not in `master`,
feature depends on a topic that is in `seen`, but not in `master`,
base your work on the tip of that topic.

* Corrections and enhancements to a topic not yet in `master` should
Expand All @@ -27,7 +27,7 @@ change is relevant to.
into the series.

* In the exceptional case that a new feature depends on several topics
not in `master`, start working on `next` or `pu` privately and send
not in `master`, start working on `next` or `seen` privately and send
out patches for discussion. Before the final merge, you may have to
wait until some of the dependent topics graduate to `master`, and
rebase your work.
Expand All @@ -37,7 +37,7 @@ change is relevant to.
these parts should be based on their trees.

To find the tip of a topic branch, run `git log --first-parent
master..pu` and look for the merge commit. The second parent of this
master..seen` and look for the merge commit. The second parent of this
commit is the tip of the topic branch.

[[separate-commits]]
Expand Down Expand Up @@ -423,7 +423,7 @@ help you find out who they are.
and cooked further and eventually graduates to `master`.

In any time between the (2)-(3) cycle, the maintainer may pick it up
from the list and queue it to `pu`, in order to make it easier for
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.

Expand All @@ -434,7 +434,7 @@ their trees themselves.
master. `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 pu if you rebase on top of
tell you if your patch is merged in `seen` if you rebase on top of
master).

* Read the Git mailing list, the maintainer regularly posts messages
Expand Down
8 changes: 4 additions & 4 deletions Documentation/git-fetch.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -255,14 +255,14 @@ refspec.
* Using refspecs explicitly:
+
------------------------------------------------
$ git fetch origin +pu:pu maint:tmp
$ git fetch origin +seen:seen maint:tmp
------------------------------------------------
+
This updates (or creates, as necessary) branches `pu` and `tmp` in
This updates (or creates, as necessary) branches `seen` and `tmp` in
the local repository by fetching from the branches (respectively)
`pu` and `maint` from the remote repository.
`seen` and `maint` from the remote repository.
+
The `pu` branch will be updated even if it does not fast-forward,
The `seen` branch will be updated even if it does not fast-forward,
because it is prefixed with a plus sign; `tmp` will not be.

* Peek at a remote's branch, without configuring the remote in your local
Expand Down
4 changes: 2 additions & 2 deletions Documentation/git-ls-remote.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu
c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
$ git remote add korg http://www.kernel.org/pub/scm/git/git.git
$ git ls-remote --tags korg v\*
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
Expand Down
10 changes: 5 additions & 5 deletions Documentation/giteveryday.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -278,13 +278,13 @@ $ git am -3 -i -s ./+to-apply <4>
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
$ git switch topic/one && git rebase master <6>
$ git switch -C pu next <7>
$ git switch -C seen next <7>
$ git merge topic/one topic/two && git merge hold/linus <8>
$ git switch maint
$ git cherry-pick master~4 <9>
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
$ git fetch ko && for branch in master maint next pu <11>
$ git fetch ko && for branch in master maint next seen <11>
do
git show-branch ko/$branch $branch <12>
done
Expand All @@ -294,14 +294,14 @@ $ git push --follow-tags ko <13>
<1> see what you were in the middle of doing, if anything.
<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`.
<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.
<5> create topic branch as needed and apply, again with sign-offs.
<6> rebase internal topic branch that has not been merged to the
master or exposed as a part of a stable branch.
<7> restart `pu` every time from the next.
<7> restart `seen` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
Expand All @@ -323,7 +323,7 @@ repository at kernel.org, and looks like this:
fetch = refs/heads/*:refs/remotes/ko/*
push = refs/heads/master
push = refs/heads/next
push = +refs/heads/pu
push = +refs/heads/seen
push = refs/heads/maint
------------

Expand Down
16 changes: 8 additions & 8 deletions Documentation/gitworkflows.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,15 +85,15 @@ As a given feature goes from experimental to stable, it also

There is a fourth official branch that is used slightly differently:

* '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
things that are not quite ready for inclusion yet (see "Integration
Branches" below).

Each of the four branches is usually a direct descendant of the one
above it.

Conceptually, the feature enters at an unstable branch (usually 'next'
or 'pu'), and "graduates" to 'master' for the next release once it is
or 'seen'), and "graduates" to 'master' for the next release once it is
considered stable enough.


Expand Down Expand Up @@ -207,7 +207,7 @@ If you make it (very) clear that this branch is going to be deleted
right after the testing, you can even publish this branch, for example
to give the testers a chance to work with it, or other developers a
chance to see if their in-progress work will be compatible. `git.git`
has such an official throw-away integration branch called 'pu'.
has such an official throw-away integration branch called 'seen'.


Branch management for a release
Expand Down Expand Up @@ -291,7 +291,7 @@ This will not happen if the content of the branches was verified as
described in the previous section.


Branch management for next and pu after a feature release
Branch management for next and seen after a feature release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After a feature release, the integration branch 'next' may optionally be
Expand Down Expand Up @@ -319,8 +319,8 @@ so.
If you do this, then you should make a public announcement indicating
that 'next' was rewound and rebuilt.

The same rewind and rebuild process may be followed for 'pu'. A public
announcement is not necessary since 'pu' is a throw-away branch, as
The same rewind and rebuild process may be followed for 'seen'. A public
announcement is not necessary since 'seen' is a throw-away branch, as
described above.


Expand Down
52 changes: 26 additions & 26 deletions Documentation/howto/maintain-git.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ this mailing list after each feature release is made.
demonstrated to be regression free. New changes are tested
in 'next' before merged to 'master'.

- 'pu' branch is used to publish other proposed changes that do
- 'seen' branch is used to publish other proposed changes that do
not yet pass the criteria set for 'next'.

- The tips of 'master' and 'maint' branches will not be rewound to
Expand All @@ -76,7 +76,7 @@ this mailing list after each feature release is made.
of the cycle.

- Usually 'master' contains all of 'maint' and 'next' contains all
of 'master'. 'pu' contains all the topics merged to 'next', but
of 'master'. 'seen' contains all the topics merged to 'next', but
is rebuilt directly on 'master'.

- The tip of 'master' is meant to be more stable than any
Expand Down Expand Up @@ -211,12 +211,12 @@ by doing the following:
series?)

- Prepare 'jch' branch, which is used to represent somewhere
between 'master' and 'pu' and often is slightly ahead of 'next'.
between 'master' and 'seen' and often is slightly ahead of 'next'.

$ Meta/Reintegrate master..pu >Meta/redo-jch.sh
$ Meta/Reintegrate master..seen >Meta/redo-jch.sh

The result is a script that lists topics to be merged in order to
rebuild 'pu' as the input to Meta/Reintegrate script. Remove
rebuild 'seen' as the input to Meta/Reintegrate script. Remove
later topics that should not be in 'jch' yet. Add a line that
consists of '### match next' before the name of the first topic
in the output that should be in 'jch' but not in 'next' yet.
Expand Down Expand Up @@ -273,29 +273,29 @@ by doing the following:
merged to 'master'. This may lose '### match next' marker;
add it again to the appropriate place when it happens.

- Rebuild 'pu'.
- Rebuild 'seen'.

$ Meta/Reintegrate master..pu >Meta/redo-pu.sh
$ Meta/Reintegrate master..seen >Meta/redo-seen.sh

Edit the result by adding new topics that are not still in 'pu'
Edit the result by adding new topics that are not still in 'seen'
in the script. Then

$ git checkout -B pu jch
$ sh Meta/redo-pu.sh
$ git checkout -B seen jch
$ sh Meta/redo-seen.sh

When all is well, clean up the redo-pu.sh script with
When all is well, clean up the redo-seen.sh script with

$ sh Meta/redo-pu.sh -u
$ sh Meta/redo-seen.sh -u

Double check by running

$ git branch --no-merged pu
$ git branch --no-merged seen

to see there is no unexpected leftover topics.

At this point, build-test the result for semantic conflicts, and
if there are, prepare an appropriate merge-fix first (see
appendix), and rebuild the 'pu' branch from scratch, starting at
appendix), and rebuild the 'seen' branch from scratch, starting at
the tip of 'jch'.

- Update "What's cooking" message to review the updates to
Expand All @@ -305,14 +305,14 @@ by doing the following:

$ Meta/cook

This script inspects the history between master..pu, finds tips
This script inspects the history between master..seen, finds tips
of topic branches, compares what it found with the current
contents in Meta/whats-cooking.txt, and updates that file.
Topics not listed in the file but are found in master..pu are
Topics not listed in the file but are found in master..seen are
added to the "New topics" section, topics listed in the file that
are no longer found in master..pu are moved to the "Graduated to
are no longer found in master..seen are moved to the "Graduated to
master" section, and topics whose commits changed their states
(e.g. used to be only in 'pu', now merged to 'next') are updated
(e.g. used to be only in 'seen', now merged to 'next') are updated
with change markers "<<" and ">>".

Look for lines enclosed in "<<" and ">>"; they hold contents from
Expand Down Expand Up @@ -342,7 +342,7 @@ Observations
Some observations to be made.

* Each topic is tested individually, and also together with other
topics cooking first in 'pu', then in 'jch' and then in 'next'.
topics cooking first in 'seen', then in 'jch' and then in 'next'.
Until it matures, no part of it is merged to 'master'.

* A topic already in 'next' can get fixes while still in
Expand Down Expand Up @@ -385,7 +385,7 @@ new use of the variable under its old name. When these two topics
are merged together, the reference to the variable newly added by
the latter topic will still use the old name in the result.

The Meta/Reintegrate script that is used by redo-jch and redo-pu
The Meta/Reintegrate script that is used by redo-jch and redo-seen
scripts implements a crude but usable way to work this issue around.
When the script merges branch $X, it checks if "refs/merge-fix/$X"
exists, and if so, the effect of it is squashed into the result of
Expand All @@ -405,14 +405,14 @@ commit that can be squashed into a result of mechanical merge to
correct semantic conflicts.

After finding that the result of merging branch "ai/topic" to an
integration branch had such a semantic conflict, say pu~4, check the
integration branch had such a semantic conflict, say seen~4, check the
problematic merge out on a detached HEAD, edit the working tree to
fix the semantic conflict, and make a separate commit to record the
fix-up:

$ git checkout pu~4
$ git checkout seen~4
$ git show -s --pretty=%s ;# double check
Merge branch 'ai/topic' to pu
Merge branch 'ai/topic' to seen
$ edit
$ git commit -m 'merge-fix/ai/topic' -a

Expand All @@ -424,9 +424,9 @@ result:
Then double check the result by asking Meta/Reintegrate to redo the
merge:

$ git checkout pu~5 ;# the parent of the problem merge
$ git checkout seen~5 ;# the parent of the problem merge
$ echo ai/topic | Meta/Reintegrate
$ git diff pu~4
$ git diff seen~4

This time, because you prepared refs/merge-fix/ai/topic, the
resulting merge should have been tweaked to include the fix for the
Expand All @@ -438,7 +438,7 @@ branch needs this merge-fix is because another branch merged earlier
to the integration branch changed the underlying assumption ai/topic
branch made (e.g. ai/topic branch added a site to refer to a
variable, while the other branch renamed that variable and adjusted
existing use sites), and if you changed redo-jch (or redo-pu) script
existing use sites), and if you changed redo-jch (or redo-seen) script
to merge ai/topic branch before the other branch, then the above
merge-fix should not be applied while merging ai/topic, but should
instead be applied while merging the other branch. You would need
Expand Down
Loading