Re: GIT 0.99.7d, and end of week status.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Sep 26, 2005, 00:01 UTC
- Message-ID
- <7v1x3cn1cj.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <200509252143.23905.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> Does that mean I have missed some step along the way to get the maint branch > position moved to the new tag?
To recap, you did:
(before 0.99.7d propagated to the mirrors)
$ git clone http://kernel.org/pub/scm/git/git.git git-src
$ cd git-src (after 0.99.7d propagated to the mirrors)
$ git fetch origin tag v0.99.7d
$ git checkout -f maintThe 'fetch origin tag v0.99.7d' step should have left the new file .git/refs/tags/v0.99.7d _after_ downloading all the objects necessary to reconstruct the history to get there.
Ah, you are right. My instruction did not update other branches for you. My bad.
Assuming people stay on their "master" branch, and have the recommended .git/remotes/origin contents in my previous message, then the steps "after 0.99.7d propagated to the mirrors" would just be:
$ git fetch
which would fetch all the branches mentioned in the remotes file, and then:
$ git checkout -f maint
which would switch your working tree to maint branch.
NOTE NOTE NOTE. The above assumes you are on your "master" branch when you run 'git fetch' --- if you are on any of the branches that is being updated (you can check which branch you are on with 'git branch' without argument, or just with 'ls -l .git/HEAD') 'git fetch' will complain because doing so without updating them to match the updated branch head would make your index file and working tree inconsistent with your .git/HEAD, but 'git fetch' is supposed to be only fetching without touching the working tree.