understanding index

understanding index

[Nicolas Sebrecht]

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

Re: understanding index

[Santi Béjar]

2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:
>
> 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
> % 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
>

Re: understanding index

[Alex Riesen]

2009/1/31 Santi Béjar <santi@agolina.net>:
> 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

Re: understanding index

[Nicolas Sebrecht]

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 ?

-- 
Nicolas Sebrecht

Re: understanding index

[Santi Béjar]

2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:
>
> 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.
>
> 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

Re: understanding index

[Björn Steinbrink]

On 2009.01.31 21:19:20 +0100, Nicolas Sebrecht wrote:
> 
> 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

Re: understanding index

[Nicolas Sebrecht]

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

> 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