mirror of
https://github.com/git/git.git
synced 2024-11-23 18:05:29 +08:00
Merge branch 'js/pu-to-seen'
The documentation and some tests have been adjusted for the recent renaming of "pu" branch to "seen". * js/pu-to-seen: tests: reference `seen` wherever `pu` was referenced docs: adjust the technical overview for the rename `pu` -> `seen` docs: adjust for the recent rename of `pu` to `seen`
This commit is contained in:
Junio C Hamano
commit
8a78e4d615
@ -1179,8 +1179,8 @@ look at the section below this one for some context.)
|
||||
[[after-approval]]
|
||||
=== 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`,
|
||||
|
||||
@ -19,7 +19,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
|
||||
@ -28,7 +28,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.
|
||||
@ -38,7 +38,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]]
|
||||
@ -424,7 +424,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.
|
||||
|
||||
@ -435,7 +435,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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
@ -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.
|
||||
@ -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
|
||||
------------
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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.
|
||||
|
||||
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
@ -229,12 +229,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.
|
||||
@ -291,29 +291,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
|
||||
@ -323,14 +323,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
|
||||
@ -360,7 +360,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
|
||||
@ -411,7 +411,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
|
||||
@ -431,14 +431,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
|
||||
|
||||
@ -450,9 +450,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
|
||||
@ -464,7 +464,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
|
||||
|
||||
@ -4,7 +4,7 @@ Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
|
||||
Subject: Re: sending changesets from the middle of a git tree
|
||||
Date: Sun, 14 Aug 2005 18:37:39 -0700
|
||||
Abstract: In this article, JC talks about how he rebases the
|
||||
public "pu" branch using the core Git tools when he updates
|
||||
public "seen" branch using the core Git tools when he updates
|
||||
the "master" branch, and how "rebase" works. Also discussed
|
||||
is how this applies to individual developers who sends patches
|
||||
upstream.
|
||||
@ -20,8 +20,8 @@ Petr Baudis <pasky@suse.cz> writes:
|
||||
> where Junio C Hamano <junkio@cox.net> told me that...
|
||||
>> Linus Torvalds <torvalds@osdl.org> writes:
|
||||
>>
|
||||
>> > Junio, maybe you want to talk about how you move patches from your "pu"
|
||||
>> > branch to the real branches.
|
||||
>> > Junio, maybe you want to talk about how you move patches from your
|
||||
>> > "seen" branch to the real branches.
|
||||
>>
|
||||
> Actually, wouldn't this be also precisely for what StGIT is intended to?
|
||||
--------------------------------------
|
||||
@ -33,12 +33,12 @@ the kind of task StGIT is designed to do.
|
||||
I just have done a simpler one, this time using only the core
|
||||
Git tools.
|
||||
|
||||
I had a handful of commits that were ahead of master in pu, and I
|
||||
I had a handful of commits that were ahead of master in 'seen', and I
|
||||
wanted to add some documentation bypassing my usual habit of
|
||||
placing new things in pu first. At the beginning, the commit
|
||||
placing new things in 'seen' first. At the beginning, the commit
|
||||
ancestry graph looked like this:
|
||||
|
||||
*"pu" head
|
||||
*"seen" head
|
||||
master --> #1 --> #2 --> #3
|
||||
|
||||
So I started from master, made a bunch of edits, and committed:
|
||||
@ -50,7 +50,7 @@ So I started from master, made a bunch of edits, and committed:
|
||||
|
||||
After the commit, the ancestry graph would look like this:
|
||||
|
||||
*"pu" head
|
||||
*"seen" head
|
||||
master^ --> #1 --> #2 --> #3
|
||||
\
|
||||
\---> master
|
||||
@ -58,31 +58,31 @@ After the commit, the ancestry graph would look like this:
|
||||
The old master is now master^ (the first parent of the master).
|
||||
The new master commit holds my documentation updates.
|
||||
|
||||
Now I have to deal with "pu" branch.
|
||||
Now I have to deal with "seen" branch.
|
||||
|
||||
This is the kind of situation I used to have all the time when
|
||||
Linus was the maintainer and I was a contributor, when you look
|
||||
at "master" branch being the "maintainer" branch, and "pu"
|
||||
at "master" branch being the "maintainer" branch, and "seen"
|
||||
branch being the "contributor" branch. Your work started at the
|
||||
tip of the "maintainer" branch some time ago, you made a lot of
|
||||
progress in the meantime, and now the maintainer branch has some
|
||||
other commits you do not have yet. And "git rebase" was written
|
||||
with the explicit purpose of helping to maintain branches like
|
||||
"pu". You _could_ merge master to pu and keep going, but if you
|
||||
"seen". You _could_ merge master to 'seen' and keep going, but if you
|
||||
eventually want to cherrypick and merge some but not necessarily
|
||||
all changes back to the master branch, it often makes later
|
||||
operations for _you_ easier if you rebase (i.e. carry forward
|
||||
your changes) "pu" rather than merge. So I ran "git rebase":
|
||||
your changes) "seen" rather than merge. So I ran "git rebase":
|
||||
|
||||
$ git checkout pu
|
||||
$ git rebase master pu
|
||||
$ git checkout seen
|
||||
$ git rebase master seen
|
||||
|
||||
What this does is to pick all the commits since the current
|
||||
branch (note that I now am on "pu" branch) forked from the
|
||||
branch (note that I now am on "seen" branch) forked from the
|
||||
master branch, and forward port these changes.
|
||||
|
||||
master^ --> #1 --> #2 --> #3
|
||||
\ *"pu" head
|
||||
\ *"seen" head
|
||||
\---> master --> #1' --> #2' --> #3'
|
||||
|
||||
The diff between master^ and #1 is applied to master and
|
||||
@ -92,7 +92,7 @@ commits are made similarly out of #2 and #3 commits.
|
||||
|
||||
Old #3 is not recorded in any of the .git/refs/heads/ file
|
||||
anymore, so after doing this you will have dangling commit if
|
||||
you ran fsck-cache, which is normal. After testing "pu", you
|
||||
you ran fsck-cache, which is normal. After testing "seen", you
|
||||
can run "git prune" to get rid of those original three commits.
|
||||
|
||||
While I am talking about "git rebase", I should talk about how
|
||||
|
||||
@ -15,7 +15,7 @@ One of the changes I pulled into the 'master' branch turns out to
|
||||
break building Git with GCC 2.95. While they were well-intentioned
|
||||
portability fixes, keeping things working with gcc-2.95 was also
|
||||
important. Here is what I did to revert the change in the 'master'
|
||||
branch and to adjust the 'pu' branch, using core Git tools and
|
||||
branch and to adjust the 'seen' branch, using core Git tools and
|
||||
barebone Porcelain.
|
||||
|
||||
First, prepare a throw-away branch in case I screw things up.
|
||||
@ -104,11 +104,11 @@ $ git diff master..revert-c99
|
||||
|
||||
says nothing.
|
||||
|
||||
Then we rebase the 'pu' branch as usual.
|
||||
Then we rebase the 'seen' branch as usual.
|
||||
|
||||
------------------------------------------------
|
||||
$ git checkout pu
|
||||
$ git tag pu-anchor pu
|
||||
$ git checkout seen
|
||||
$ git tag seen-anchor seen
|
||||
$ git rebase master
|
||||
* Applying: Redo "revert" using three-way merge machinery.
|
||||
First trying simple merge strategy to cherry-pick.
|
||||
@ -127,11 +127,11 @@ First trying simple merge strategy to cherry-pick.
|
||||
First trying simple merge strategy to cherry-pick.
|
||||
------------------------------------------------
|
||||
|
||||
The temporary tag 'pu-anchor' is me just being careful, in case 'git
|
||||
The temporary tag 'seen-anchor' is me just being careful, in case 'git
|
||||
rebase' screws up. After this, I can do these for sanity check:
|
||||
|
||||
------------------------------------------------
|
||||
$ git diff pu-anchor..pu ;# make sure we got the master fix.
|
||||
$ git diff seen-anchor..seen ;# make sure we got the master fix.
|
||||
$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
|
||||
$ make clean test ;# make sure it did not cause other breakage.
|
||||
------------------------------------------------
|
||||
@ -140,7 +140,7 @@ Everything is in the good order. I do not need the temporary branch
|
||||
or tag anymore, so remove them:
|
||||
|
||||
------------------------------------------------
|
||||
$ rm -f .git/refs/tags/pu-anchor
|
||||
$ rm -f .git/refs/tags/seen-anchor
|
||||
$ git branch -d revert-c99
|
||||
------------------------------------------------
|
||||
|
||||
@ -168,18 +168,18 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
|
||||
And the final repository status looks like this:
|
||||
|
||||
------------------------------------------------
|
||||
$ git show-branch --more=1 master pu rc
|
||||
$ git show-branch --more=1 master seen rc
|
||||
! [master] Revert "Replace zero-length array decls with []."
|
||||
! [pu] git-repack: Add option to repack all objects.
|
||||
! [seen] git-repack: Add option to repack all objects.
|
||||
* [rc] Merge refs/heads/master from .
|
||||
---
|
||||
+ [pu] git-repack: Add option to repack all objects.
|
||||
+ [pu~1] More documentation updates.
|
||||
+ [pu~2] Show commits in topo order and name all commits.
|
||||
+ [pu~3] mailinfo and applymbox updates
|
||||
+ [pu~4] Document "git cherry-pick" and "git revert"
|
||||
+ [pu~5] Remove git-apply-patch-script.
|
||||
+ [pu~6] Redo "revert" using three-way merge machinery.
|
||||
+ [seen] git-repack: Add option to repack all objects.
|
||||
+ [seen~1] More documentation updates.
|
||||
+ [seen~2] Show commits in topo order and name all commits.
|
||||
+ [seen~3] mailinfo and applymbox updates
|
||||
+ [seen~4] Document "git cherry-pick" and "git revert"
|
||||
+ [seen~5] Remove git-apply-patch-script.
|
||||
+ [seen~6] Redo "revert" using three-way merge machinery.
|
||||
- [rc] Merge refs/heads/master from .
|
||||
++* [master] Revert "Replace zero-length array decls with []."
|
||||
- [rc~1] Merge refs/heads/master from .
|
||||
|
||||
@ -179,7 +179,7 @@ allowed-groups, to describe which heads can be pushed into by
|
||||
whom. The format of each file would look like this:
|
||||
|
||||
refs/heads/master junio
|
||||
+refs/heads/pu junio
|
||||
+refs/heads/seen junio
|
||||
refs/heads/cogito$ pasky
|
||||
refs/heads/bw/.* linus
|
||||
refs/heads/tmp/.* .*
|
||||
@ -187,6 +187,6 @@ whom. The format of each file would look like this:
|
||||
|
||||
With this, Linus can push or create "bw/penguin" or "bw/zebra"
|
||||
or "bw/panda" branches, Pasky can do only "cogito", and JC can
|
||||
do master and pu branches and make versioned tags. And anybody
|
||||
can do tmp/blah branches. The '+' sign at the pu record means
|
||||
do master and "seen" branches and make versioned tags. And anybody
|
||||
can do tmp/blah branches. The '+' sign at the "seen" record means
|
||||
that JC can make non-fast-forward pushes on it.
|
||||
|
||||
@ -347,7 +347,7 @@ $ git branch -r
|
||||
origin/man
|
||||
origin/master
|
||||
origin/next
|
||||
origin/pu
|
||||
origin/seen
|
||||
origin/todo
|
||||
------------------------------------------------
|
||||
|
||||
|
||||
@ -988,7 +988,7 @@ test_expect_success 'remote set-branches' '
|
||||
+refs/heads/maint:refs/remotes/scratch/maint
|
||||
+refs/heads/master:refs/remotes/scratch/master
|
||||
+refs/heads/next:refs/remotes/scratch/next
|
||||
+refs/heads/pu:refs/remotes/scratch/pu
|
||||
+refs/heads/seen:refs/remotes/scratch/seen
|
||||
+refs/heads/t/topic:refs/remotes/scratch/t/topic
|
||||
EOF
|
||||
sort <<-\EOF >expect.setup-ffonly &&
|
||||
@ -998,7 +998,7 @@ test_expect_success 'remote set-branches' '
|
||||
sort <<-\EOF >expect.respect-ffonly &&
|
||||
refs/heads/master:refs/remotes/scratch/master
|
||||
+refs/heads/next:refs/remotes/scratch/next
|
||||
+refs/heads/pu:refs/remotes/scratch/pu
|
||||
+refs/heads/seen:refs/remotes/scratch/seen
|
||||
EOF
|
||||
|
||||
git clone .git/ setbranches &&
|
||||
@ -1016,7 +1016,7 @@ test_expect_success 'remote set-branches' '
|
||||
git config --get-all remote.scratch.fetch >config-result &&
|
||||
sort <config-result >../actual.replace &&
|
||||
|
||||
git remote set-branches --add scratch pu t/topic &&
|
||||
git remote set-branches --add scratch seen t/topic &&
|
||||
git config --get-all remote.scratch.fetch >config-result &&
|
||||
sort <config-result >../actual.add-two &&
|
||||
|
||||
@ -1028,7 +1028,7 @@ test_expect_success 'remote set-branches' '
|
||||
git config --get-all remote.scratch.fetch >config-result &&
|
||||
sort <config-result >../actual.setup-ffonly &&
|
||||
|
||||
git remote set-branches --add scratch pu &&
|
||||
git remote set-branches --add scratch seen &&
|
||||
git config --get-all remote.scratch.fetch >config-result &&
|
||||
sort <config-result >../actual.respect-ffonly
|
||||
) &&
|
||||
|
||||
@ -747,42 +747,42 @@ test_expect_success 'deletion of a non-existent ref alone does trigger post-rece
|
||||
'
|
||||
|
||||
test_expect_success 'mixed ref updates, deletes, invalid deletes trigger hooks with correct input' '
|
||||
mk_test_with_hooks testrepo heads/master heads/next heads/pu &&
|
||||
mk_test_with_hooks testrepo heads/master heads/next heads/seen &&
|
||||
orgmaster=$(cd testrepo && git show-ref -s --verify refs/heads/master) &&
|
||||
newmaster=$(git show-ref -s --verify refs/heads/master) &&
|
||||
orgnext=$(cd testrepo && git show-ref -s --verify refs/heads/next) &&
|
||||
newnext=$ZERO_OID &&
|
||||
orgpu=$(cd testrepo && git show-ref -s --verify refs/heads/pu) &&
|
||||
newpu=$(git show-ref -s --verify refs/heads/master) &&
|
||||
orgseen=$(cd testrepo && git show-ref -s --verify refs/heads/seen) &&
|
||||
newseen=$(git show-ref -s --verify refs/heads/master) &&
|
||||
git push testrepo refs/heads/master:refs/heads/master \
|
||||
refs/heads/master:refs/heads/pu :refs/heads/next \
|
||||
refs/heads/master:refs/heads/seen :refs/heads/next \
|
||||
:refs/heads/nonexistent &&
|
||||
(
|
||||
cd testrepo/.git &&
|
||||
cat >pre-receive.expect <<-EOF &&
|
||||
$orgmaster $newmaster refs/heads/master
|
||||
$orgnext $newnext refs/heads/next
|
||||
$orgpu $newpu refs/heads/pu
|
||||
$orgseen $newseen refs/heads/seen
|
||||
$ZERO_OID $ZERO_OID refs/heads/nonexistent
|
||||
EOF
|
||||
|
||||
cat >update.expect <<-EOF &&
|
||||
refs/heads/master $orgmaster $newmaster
|
||||
refs/heads/next $orgnext $newnext
|
||||
refs/heads/pu $orgpu $newpu
|
||||
refs/heads/seen $orgseen $newseen
|
||||
refs/heads/nonexistent $ZERO_OID $ZERO_OID
|
||||
EOF
|
||||
|
||||
cat >post-receive.expect <<-EOF &&
|
||||
$orgmaster $newmaster refs/heads/master
|
||||
$orgnext $newnext refs/heads/next
|
||||
$orgpu $newpu refs/heads/pu
|
||||
$orgseen $newseen refs/heads/seen
|
||||
EOF
|
||||
|
||||
cat >post-update.expect <<-EOF &&
|
||||
refs/heads/master
|
||||
refs/heads/next
|
||||
refs/heads/pu
|
||||
refs/heads/seen
|
||||
EOF
|
||||
|
||||
test_cmp pre-receive.expect pre-receive.actual &&
|
||||
|
||||
@ -494,7 +494,7 @@ test_expect_success '__gitcomp - prefix' '
|
||||
'
|
||||
|
||||
test_expect_success '__gitcomp - suffix' '
|
||||
test_gitcomp "branch.me" "master maint next pu" "branch." \
|
||||
test_gitcomp "branch.me" "master maint next seen" "branch." \
|
||||
"ma" "." <<-\EOF
|
||||
branch.master.Z
|
||||
branch.maint.Z
|
||||
@ -545,7 +545,7 @@ read -r -d "" refs <<-\EOF
|
||||
maint
|
||||
master
|
||||
next
|
||||
pu
|
||||
seen
|
||||
EOF
|
||||
|
||||
test_expect_success '__gitcomp_nl - trailing space' '
|
||||
|
||||
Loading…
Reference in New Issue
Block a user