cache status after git pull

2005-08-25 Thread tony . luck
* When the branch head pointed by $GIT_DIR/HEAD changes while
 the index file and working tree are looking the other way
 (e.g. somebody pushed into your repository, or you ran git
 fetch to update the ref your working tree is on), git
 checkout without -f gets confused.  Figure out a good way to
 handle this.

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)? At
the time the blame was placed on a failed merge not being backed
out correctly.  But I only had the failed merge because get checkout
had failed to switch branches (and not provided an exit code to
stop my script from trying the merge).

Here's what I did this morning.

1) Updated my linus branch:

  $ git checkout linus  git pull linus

This appeared to work just fine ... except that when I
check the status of my tree I see:

  $ git status
  #
  # Updated but not checked in:
  #   (will commit)
  #
  #   modified: arch/ia64/pci/pci.c
  #   modified: arch/ppc64/kernel/setup.c
  #   modified: arch/sparc64/kernel/pci.c
  #   modified: arch/x86_64/defconfig
  #   modified: drivers/block/cfq-iosched.c
  #   modified: include/asm-m68k/page.h
  #   modified: kernel/cpuset.c
  #
  #
  # On branch refs/heads/linus
  
Which looks like a set of landmines just waiting for me to
step on them!

Today these didn't bite me.  git checkout release worked
and switched to my release branch (and git status went back
to saying nothing to commit).  But in the past I think
this is the situation that has caused git checkout to fail
with the fatal: Entry 'blah' would be overwritten by merge. Cannot merge.

-Tony
-
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


Re: cache status after git pull

2005-08-25 Thread Junio C Hamano
[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


Re: cache status after git pull

2005-08-25 Thread Junio C Hamano
Luck, Tony [EMAIL PROTECTED] writes:

 What I want is to get the latest from kernel.org...linus...master
 and update my .refs/heads/linus with the new SHA1.

 I'd like to be able to do that without touching what is in my
 index, and without changing the state of any checked out files.

 If that is what the above does,...

At least that is how git fetch repo src:dst is designed
to work, and Pull: src:dst in a remotes/ shorthand is
designed to reduce typing while doing so.  Please bug me if
things do not work as advertised.



-
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