docs: adjust the technical overview for the rename pu
-> seen
This patch tries to rewrite history a bit: the mail contents that have been added to Git's source code are actually fixed, we cannot change them in hindsight. But as the `pu` branch _was_ renamed, and as the documents were added to Git's source code not so much as historical record, but to describe the status quo, let's pretend that we have a time machine and adjust the provided information accordingly. Where appropriate, quotes were added for readability. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
828197de8f
commit
77dc6049c3
@ -66,7 +66,7 @@ this mailing list after each feature release is made.
|
|||||||
demonstrated to be regression free. New changes are tested
|
demonstrated to be regression free. New changes are tested
|
||||||
in 'next' before merged to 'master'.
|
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'.
|
not yet pass the criteria set for 'next'.
|
||||||
|
|
||||||
- The tips of 'master' and 'maint' branches will not be rewound to
|
- 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.
|
of the cycle.
|
||||||
|
|
||||||
- Usually 'master' contains all of 'maint' and 'next' contains all
|
- 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'.
|
is rebuilt directly on 'master'.
|
||||||
|
|
||||||
- The tip of 'master' is meant to be more stable than any
|
- The tip of 'master' is meant to be more stable than any
|
||||||
@ -211,12 +211,12 @@ by doing the following:
|
|||||||
series?)
|
series?)
|
||||||
|
|
||||||
- Prepare 'jch' branch, which is used to represent somewhere
|
- 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
|
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
|
later topics that should not be in 'jch' yet. Add a line that
|
||||||
consists of '### match next' before the name of the first topic
|
consists of '### match next' before the name of the first topic
|
||||||
in the output that should be in 'jch' but not in 'next' yet.
|
in the output that should be in 'jch' but not in 'next' yet.
|
||||||
@ -273,29 +273,29 @@ by doing the following:
|
|||||||
merged to 'master'. This may lose '### match next' marker;
|
merged to 'master'. This may lose '### match next' marker;
|
||||||
add it again to the appropriate place when it happens.
|
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
|
in the script. Then
|
||||||
|
|
||||||
$ git checkout -B pu jch
|
$ git checkout -B seen jch
|
||||||
$ sh Meta/redo-pu.sh
|
$ 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
|
Double check by running
|
||||||
|
|
||||||
$ git branch --no-merged pu
|
$ git branch --no-merged seen
|
||||||
|
|
||||||
to see there is no unexpected leftover topics.
|
to see there is no unexpected leftover topics.
|
||||||
|
|
||||||
At this point, build-test the result for semantic conflicts, and
|
At this point, build-test the result for semantic conflicts, and
|
||||||
if there are, prepare an appropriate merge-fix first (see
|
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'.
|
the tip of 'jch'.
|
||||||
|
|
||||||
- Update "What's cooking" message to review the updates to
|
- Update "What's cooking" message to review the updates to
|
||||||
@ -305,14 +305,14 @@ by doing the following:
|
|||||||
|
|
||||||
$ Meta/cook
|
$ 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
|
of topic branches, compares what it found with the current
|
||||||
contents in Meta/whats-cooking.txt, and updates that file.
|
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
|
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
|
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 ">>".
|
with change markers "<<" and ">>".
|
||||||
|
|
||||||
Look for lines enclosed in "<<" and ">>"; they hold contents from
|
Look for lines enclosed in "<<" and ">>"; they hold contents from
|
||||||
@ -342,7 +342,7 @@ Observations
|
|||||||
Some observations to be made.
|
Some observations to be made.
|
||||||
|
|
||||||
* Each topic is tested individually, and also together with other
|
* 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'.
|
Until it matures, no part of it is merged to 'master'.
|
||||||
|
|
||||||
* A topic already in 'next' can get fixes while still in
|
* A topic already in 'next' can get fixes while still in
|
||||||
@ -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
|
are merged together, the reference to the variable newly added by
|
||||||
the latter topic will still use the old name in the result.
|
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.
|
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"
|
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
|
exists, and if so, the effect of it is squashed into the result of
|
||||||
@ -405,14 +405,14 @@ commit that can be squashed into a result of mechanical merge to
|
|||||||
correct semantic conflicts.
|
correct semantic conflicts.
|
||||||
|
|
||||||
After finding that the result of merging branch "ai/topic" to an
|
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
|
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 the semantic conflict, and make a separate commit to record the
|
||||||
fix-up:
|
fix-up:
|
||||||
|
|
||||||
$ git checkout pu~4
|
$ git checkout seen~4
|
||||||
$ git show -s --pretty=%s ;# double check
|
$ git show -s --pretty=%s ;# double check
|
||||||
Merge branch 'ai/topic' to pu
|
Merge branch 'ai/topic' to seen
|
||||||
$ edit
|
$ edit
|
||||||
$ git commit -m 'merge-fix/ai/topic' -a
|
$ git commit -m 'merge-fix/ai/topic' -a
|
||||||
|
|
||||||
@ -424,9 +424,9 @@ result:
|
|||||||
Then double check the result by asking Meta/Reintegrate to redo the
|
Then double check the result by asking Meta/Reintegrate to redo the
|
||||||
merge:
|
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
|
$ echo ai/topic | Meta/Reintegrate
|
||||||
$ git diff pu~4
|
$ git diff seen~4
|
||||||
|
|
||||||
This time, because you prepared refs/merge-fix/ai/topic, the
|
This time, because you prepared refs/merge-fix/ai/topic, the
|
||||||
resulting merge should have been tweaked to include the fix for the
|
resulting merge should have been tweaked to include the fix for the
|
||||||
@ -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
|
to the integration branch changed the underlying assumption ai/topic
|
||||||
branch made (e.g. ai/topic branch added a site to refer to a
|
branch made (e.g. ai/topic branch added a site to refer to a
|
||||||
variable, while the other branch renamed that variable and adjusted
|
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
|
to merge ai/topic branch before the other branch, then the above
|
||||||
merge-fix should not be applied while merging ai/topic, but should
|
merge-fix should not be applied while merging ai/topic, but should
|
||||||
instead be applied while merging the other branch. You would need
|
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
|
Subject: Re: sending changesets from the middle of a git tree
|
||||||
Date: Sun, 14 Aug 2005 18:37:39 -0700
|
Date: Sun, 14 Aug 2005 18:37:39 -0700
|
||||||
Abstract: In this article, JC talks about how he rebases the
|
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
|
the "master" branch, and how "rebase" works. Also discussed
|
||||||
is how this applies to individual developers who sends patches
|
is how this applies to individual developers who sends patches
|
||||||
upstream.
|
upstream.
|
||||||
@ -20,8 +20,8 @@ Petr Baudis <pasky@suse.cz> writes:
|
|||||||
> where Junio C Hamano <junkio@cox.net> told me that...
|
> where Junio C Hamano <junkio@cox.net> told me that...
|
||||||
>> Linus Torvalds <torvalds@osdl.org> writes:
|
>> Linus Torvalds <torvalds@osdl.org> writes:
|
||||||
>>
|
>>
|
||||||
>> > Junio, maybe you want to talk about how you move patches from your "pu"
|
>> > Junio, maybe you want to talk about how you move patches from your
|
||||||
>> > branch to the real branches.
|
>> > "seen" branch to the real branches.
|
||||||
>>
|
>>
|
||||||
> Actually, wouldn't this be also precisely for what StGIT is intended to?
|
> 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
|
I just have done a simpler one, this time using only the core
|
||||||
Git tools.
|
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
|
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:
|
ancestry graph looked like this:
|
||||||
|
|
||||||
*"pu" head
|
*"seen" head
|
||||||
master --> #1 --> #2 --> #3
|
master --> #1 --> #2 --> #3
|
||||||
|
|
||||||
So I started from master, made a bunch of edits, and committed:
|
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:
|
After the commit, the ancestry graph would look like this:
|
||||||
|
|
||||||
*"pu" head
|
*"seen" head
|
||||||
master^ --> #1 --> #2 --> #3
|
master^ --> #1 --> #2 --> #3
|
||||||
\
|
\
|
||||||
\---> master
|
\---> 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 old master is now master^ (the first parent of the master).
|
||||||
The new master commit holds my documentation updates.
|
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
|
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
|
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
|
branch being the "contributor" branch. Your work started at the
|
||||||
tip of the "maintainer" branch some time ago, you made a lot of
|
tip of the "maintainer" branch some time ago, you made a lot of
|
||||||
progress in the meantime, and now the maintainer branch has some
|
progress in the meantime, and now the maintainer branch has some
|
||||||
other commits you do not have yet. And "git rebase" was written
|
other commits you do not have yet. And "git rebase" was written
|
||||||
with the explicit purpose of helping to maintain branches like
|
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
|
eventually want to cherrypick and merge some but not necessarily
|
||||||
all changes back to the master branch, it often makes later
|
all changes back to the master branch, it often makes later
|
||||||
operations for _you_ easier if you rebase (i.e. carry forward
|
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 checkout seen
|
||||||
$ git rebase master pu
|
$ git rebase master seen
|
||||||
|
|
||||||
What this does is to pick all the commits since the current
|
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 branch, and forward port these changes.
|
||||||
|
|
||||||
master^ --> #1 --> #2 --> #3
|
master^ --> #1 --> #2 --> #3
|
||||||
\ *"pu" head
|
\ *"seen" head
|
||||||
\---> master --> #1' --> #2' --> #3'
|
\---> master --> #1' --> #2' --> #3'
|
||||||
|
|
||||||
The diff between master^ and #1 is applied to master and
|
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
|
Old #3 is not recorded in any of the .git/refs/heads/ file
|
||||||
anymore, so after doing this you will have dangling commit if
|
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.
|
can run "git prune" to get rid of those original three commits.
|
||||||
|
|
||||||
While I am talking about "git rebase", I should talk about how
|
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
|
break building Git with GCC 2.95. While they were well-intentioned
|
||||||
portability fixes, keeping things working with gcc-2.95 was also
|
portability fixes, keeping things working with gcc-2.95 was also
|
||||||
important. Here is what I did to revert the change in the 'master'
|
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.
|
barebone Porcelain.
|
||||||
|
|
||||||
First, prepare a throw-away branch in case I screw things up.
|
First, prepare a throw-away branch in case I screw things up.
|
||||||
@ -104,11 +104,11 @@ $ git diff master..revert-c99
|
|||||||
|
|
||||||
says nothing.
|
says nothing.
|
||||||
|
|
||||||
Then we rebase the 'pu' branch as usual.
|
Then we rebase the 'seen' branch as usual.
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
$ git checkout pu
|
$ git checkout seen
|
||||||
$ git tag pu-anchor pu
|
$ git tag seen-anchor seen
|
||||||
$ git rebase master
|
$ git rebase master
|
||||||
* Applying: Redo "revert" using three-way merge machinery.
|
* Applying: Redo "revert" using three-way merge machinery.
|
||||||
First trying simple merge strategy to cherry-pick.
|
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.
|
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:
|
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 CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
|
||||||
$ make clean test ;# make sure it did not cause other 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:
|
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
|
$ git branch -d revert-c99
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
@ -168,18 +168,18 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
|
|||||||
And the final repository status looks like this:
|
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 []."
|
! [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 .
|
* [rc] Merge refs/heads/master from .
|
||||||
---
|
---
|
||||||
+ [pu] git-repack: Add option to repack all objects.
|
+ [seen] git-repack: Add option to repack all objects.
|
||||||
+ [pu~1] More documentation updates.
|
+ [seen~1] More documentation updates.
|
||||||
+ [pu~2] Show commits in topo order and name all commits.
|
+ [seen~2] Show commits in topo order and name all commits.
|
||||||
+ [pu~3] mailinfo and applymbox updates
|
+ [seen~3] mailinfo and applymbox updates
|
||||||
+ [pu~4] Document "git cherry-pick" and "git revert"
|
+ [seen~4] Document "git cherry-pick" and "git revert"
|
||||||
+ [pu~5] Remove git-apply-patch-script.
|
+ [seen~5] Remove git-apply-patch-script.
|
||||||
+ [pu~6] Redo "revert" using three-way merge machinery.
|
+ [seen~6] Redo "revert" using three-way merge machinery.
|
||||||
- [rc] Merge refs/heads/master from .
|
- [rc] Merge refs/heads/master from .
|
||||||
++* [master] Revert "Replace zero-length array decls with []."
|
++* [master] Revert "Replace zero-length array decls with []."
|
||||||
- [rc~1] Merge refs/heads/master from .
|
- [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:
|
whom. The format of each file would look like this:
|
||||||
|
|
||||||
refs/heads/master junio
|
refs/heads/master junio
|
||||||
+refs/heads/pu junio
|
+refs/heads/seen junio
|
||||||
refs/heads/cogito$ pasky
|
refs/heads/cogito$ pasky
|
||||||
refs/heads/bw/.* linus
|
refs/heads/bw/.* linus
|
||||||
refs/heads/tmp/.* .*
|
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"
|
With this, Linus can push or create "bw/penguin" or "bw/zebra"
|
||||||
or "bw/panda" branches, Pasky can do only "cogito", and JC can
|
or "bw/panda" branches, Pasky can do only "cogito", and JC can
|
||||||
do master and pu branches and make versioned tags. And anybody
|
do master and "seen" branches and make versioned tags. And anybody
|
||||||
can do tmp/blah branches. The '+' sign at the pu record means
|
can do tmp/blah branches. The '+' sign at the "seen" record means
|
||||||
that JC can make non-fast-forward pushes on it.
|
that JC can make non-fast-forward pushes on it.
|
||||||
|
Loading…
Reference in New Issue
Block a user