# understanding index 7 messages from 2009-01-31 to 2009-01-31. Participants: Nicolas Sebrecht, Santi Béjar, Alex Riesen, Björn Steinbrink. Thread: https://gitlist.dev/t/17472 ## Nicolas Sebrecht, 2009-01-31 11:10 Subject: understanding index Message-ID: <20090131111011.GA29748@ultras> URL: https://gitlist.dev/e/20090131111011.GA29748%40ultras ``` 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, 2009-01-31 12:09 Subject: Re: understanding index Message-ID: URL: https://gitlist.dev/e/adf1fd3d0901310409y28dc493ak358749e0c29154cc%40mail.gmail.com In-Reply-To: <20090131111011.GA29748@ultras> ``` 2009/1/31 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 ] > You omitted the help message of git status, where it says how to unstage: # Changes to be committed: # (use "git reset HEAD ..." 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 > ``` ## Alex Riesen, 2009-01-31 14:45 Subject: Re: understanding index Message-ID: <81b0412b0901310645t4307f67vf546e9c1c8c07701@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0901310645t4307f67vf546e9c1c8c07701%40mail.gmail.com In-Reply-To: ``` 2009/1/31 Santi Béjar : > 2009/1/31 Nicolas Sebrecht : >> 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, 2009-01-31 20:19 Subject: Re: understanding index Message-ID: <20090131201920.GC29748@ultras> URL: https://gitlist.dev/e/20090131201920.GC29748%40ultras In-Reply-To: ``` 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 ..." 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, 2009-01-31 20:57 Subject: Re: understanding index Message-ID: URL: https://gitlist.dev/e/adf1fd3d0901311257j1501d222nc24514b013bd13f3%40mail.gmail.com In-Reply-To: <20090131201920.GC29748@ultras> ``` 2009/1/31 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 ..." 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 ..." to unstage) # # modified: Makefile # # Changed but not updated: # (use "git add ..." 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 ``` ## Björn Steinbrink, 2009-01-31 21:18 Subject: Re: understanding index Message-ID: <20090131211800.GA30645@atjola.homenet> URL: https://gitlist.dev/e/20090131211800.GA30645%40atjola.homenet In-Reply-To: <20090131201920.GC29748@ultras> ``` 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 ..." 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 ``` ## Nicolas Sebrecht, 2009-01-31 22:07 Subject: Re: understanding index Message-ID: <20090131220712.GE29748@ultras> URL: https://gitlist.dev/e/20090131220712.GE29748%40ultras In-Reply-To: ``` 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 ```