threads / discuss / 17472

understanding index

Subject: understanding index

## tl;dr

7 messages between Jan 31, 2009 and Jan 31, 2009.

replies: 6people: 4as markdown or json

Nicolas Sebrecht· Jan 31, 2009, 11:10 UTC · lore

Hey list.

I'm having some understanding trouble with git index. As I understand, 'git rm --cached' is not strictly the opposite of 'git add'. It's a little embarrassing in this particular case : what if you want to commit and did a wrong 'git add -u' command ?

Here's a minimalist sample :

% ls foo bar

[ hack, hack, hack on both files ]

% git status
[...]
	modified: foo
	modified: bar
[...]
% git add -u foo bar

[ optional hack on foo ] [ damn, you realize you don't want to commit changes on foo at all ]

% git rm --cached foo
% git status
[...]
	deleted: foo
	modified: bar
[...]

If committed as is, foo will be marked as deleted (in 'git log --name-status' at least, which is not wanted).

How to retrieve the state before the wrong 'git add -u' command _and_ keep the working tree as well (including last hacks) ? Is there any command which is the exact opposite of 'git add -u' ?

Cheers,

-- 
Nicolas Sebrecht

Santi Béjar· Jan 31, 2009, 12:09 UTC · re: Nicolas Sebrecht · lore

Re: understanding index

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

Show 25 quoted lines

>
> Hey list.
>
> I'm having some understanding trouble with git index. As I understand,
> 'git rm --cached' is not strictly the opposite of 'git add'. It's a
> little embarrassing in this particular case : what if you want to
> commit and did a wrong 'git add -u' command ?
>
> Here's a minimalist sample :
>
> % ls
> foo     bar
>
> [ hack, hack, hack on both files ]
>
> % git status
> [...]
>        modified: foo
>        modified: bar
> [...]
> % git add -u foo bar
>
> [ optional hack on foo ]
> [ damn, you realize you don't want to commit changes on foo at all ]
>

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

HTH, Santi

Show 24 quoted lines

> % git rm --cached foo
> % git status
> [...]
>        deleted: foo
>        modified: bar
> [...]
>
> If committed as is, foo will be marked as deleted (in 'git log
> --name-status' at least, which is not wanted).
>
> How to retrieve the state before the wrong 'git add -u' command _and_
> keep the working tree as well (including last hacks) ? Is there any
> command which is the exact opposite of 'git add -u' ?
>
> Cheers,
>
> --
> Nicolas Sebrecht
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Alex Riesen· Jan 31, 2009, 14:45 UTC · re: Santi Béjar · lore

Re: understanding index

2009/1/31 Santi Béjar <santi@agolina.net>:

Show 10 quoted lines

> 2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:
>> I'm having some understanding trouble with git index. As I understand,
>> 'git rm --cached' is not strictly the opposite of 'git add'. It's a
>> little embarrassing in this particular case : what if you want to
>> commit and did a wrong 'git add -u' command ?
>>
> So to not commit foo at all:
>
> git reset HEAD foo
>

Or look at git gui, which allows you to select the not-to-commit parts visually

Nicolas Sebrecht· Jan 31, 2009, 20:19 UTC · re: Santi Béjar · lore

Re: understanding index

On Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:

Show 7 quoted lines

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

-- 
Nicolas Sebrecht

Santi Béjar· Jan 31, 2009, 20:57 UTC · re: Nicolas Sebrecht · lore

Re: understanding index

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

Nicolas Sebrecht· Jan 31, 2009, 22:07 UTC · re: Santi Béjar · lore

Re: understanding index

On Sat, Jan 31, 2009 at 09:57:29PM +0100, Santi Béjar wrote:

Show 7 quoted lines

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

Thank you all for the explanations.

-- 
Nicolas Sebrecht

Björn Steinbrink· Jan 31, 2009, 21:18 UTC · re: Nicolas Sebrecht · lore

Re: understanding index

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