[EMAIL PROTECTED] writes:
> Aha ... is this the problem that caught me out last week (when
> I ended up with 10 extra files attached to one of my commits)?
Plausible.
> 1) Updated my "linus" branch:
>
> $ git checkout linus && git pull linus
I would assume that just after "git checkout linus" before "git
pull linus", running "git diff -r linus" would have said
nothing.
The second command, "git pull linus", would internally run "git
fetch linus". It depends on how your shorthand "linus" is
defined, but if it is set to update (either overwrite or
fast-forward) the "linus" branch head, then your HEAD pointer
would be updated without updating the index and working tree.
This is bad because now you are telling git that your working
tree is based on updated "linus" branch head, and what you
_could_ commit on top of it is the same thing as what old
"linus" branch head commit used to have. That's why "git
status" output shows the minefield.
If I keep copies of foreign brahches in $GIT_DIR/refs/heads/
somewhere, I never checkout those branches in my working tree.
I always stay in my branches to do my work. I may "diff"
against them to see where I am. Of course I would "resolve"
with them when I feel I am ready.
So, assumes that "linus" short-hand is set up to update
$GIT_DIR/refs/heads/linus with the foreign branch head, the
above example would have been:
$ git checkout master && git pull linus
: examine diffs and be convinced what Linus does is always right.
If my "master" branch is not ready to merge from Linus but I
want to get a feel of what is coming, I would instead do:
: while staying on my master branch
$ git fetch linus
$ gitk linus master ;# or git show-branch linus master
and later when my branch is ready, I would merge it into my
master:
: still staying on my master branch
$ git pull . linus
If you did the pull into your master but it turns out that the
merge result is too messy, you could always reset (back to the
first example):
$ git checkout master && git pull linus
: if merge failed...
$ git reset --hard master
$ git checkout master && git pull linus
: merge succeeds, but I realize that my tree was not quite
: ready to merge from linus -- going back to pre-merge state
$ git reset --hard master^1
The rules for updating $GIT_DIR/refs/ when fetch happens have
been extended and clarified in 0.99.5 quite a bit.
To set up "linus" short-hand to be updated with "master" branch
head from Linus, you would do one of the following:
* Using old style shorthand
$ echo >$GIT_DIR/branches/linus \
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
$ git fetch linus
* Using new style shorthand
$ cat >$GIT_DIR/remotes/linus \
URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Pull: master:linus
$ git fetch linus
* From the command line, having either branches/linus or
remotes/linus from the above two examples:
$ git fetch linus master:linus
To set up "linus" short-hand _not_ to update any local branch
head (i.e. you only use "pull" to update your local branch,
which can be named "linus" branch), you would do one of the
following:
* Using old style shorthand
There is no way to do this using old style shorthand without
an explicit command line <refspec>. See the "From the
command line" example below how to do this.
* Using new style shorthand
$ cat >$GIT_DIR/remotes/linus \
URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Pull: master:
$ git fetch linus
* From the command line, having either branches/linus or
remotes/linus from the above two examples:
$ git fetch linus master:
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
