Re: understanding index

From: Santi Béjar <santi@agolina.net>
Date: Jan 31, 2009, 12:09 UTC
Message-ID: <adf1fd3d0901310409y28dc493ak358749e0c29154cc@mail.gmail.com>
In-Reply-To: <20090131111011.GA29748@ultras>

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
>