Re: understanding index

From: Santi Béjar <santi@agolina.net>
Date: Jan 31, 2009, 20:57 UTC
Message-ID: <adf1fd3d0901311257j1501d222nc24514b013bd13f3@mail.gmail.com>
In-Reply-To: <20090131201920.GC29748@ultras>

2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:

Show 12 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.

These help messages (helpful messages?) were not in old version, but in current git you get this indications when you execute "git status", and it was what you put as "[...]".

$ git status # On branch next # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: Makefile # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: Makefile #

> 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).

By default git reset only acts on the head of the branch and the index, so with:

git reset HEAD foo

what you are saying is, use the HEAD as the head of the branch (don't change my branch), but put in the index the state of foo in HEAD, so in brief reset the index state of foo.

Show 5 quoted lines

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

Right.

HTH, Santi