Re: understanding index

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Jan 31, 2009, 21:18 UTC
Message-ID: <20090131211800.GA30645@atjola.homenet>
In-Reply-To: <20090131201920.GC29748@ultras>

On 2009.01.31 21:19:20 +0100, Nicolas Sebrecht wrote:

Show 22 quoted lines

> 
> On Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:
> 
> > You omitted the help message of git status, where it says how to unstage:
> > # Changes to be committed:
> > #   (use "git reset HEAD <file>..." to unstage)
> > 
> > So to not commit foo at all:
> > 
> > git reset HEAD foo
> 
> Thanks. I didn't omitted the help message of git status. The "unstage"
> action is what I was looking for but I was wrongly presuming (and I've
> read git docs !) that 'HEAD' is a kind of shortcut to the last commit of
> the current branch (not to the last state of the working tree).
> 
> Working on branch master for example, we have in .git/HEAD :
> ref: refs/heads/master
> And in .git/refs/heads/master, the hash of the last commit of branch
> master.
> 
> I'm missing something here. But what ?

You're missing the fact that you want to reset the index entry to the state from HEAD. The working tree state is the modified one, and you get that into the index using "git add". But you want the index entry to be back at the state from HEAD. So HEAD is what you need to pass to reset (well, actually, you can skip "HEAD" there, it's the default).

Björn