{"thread":{"id":"17472","subject":"understanding index","startedAt":"2009-01-31T11:10:11Z","lastAt":"2009-01-31T22:07:12Z","messageCount":7,"participants":["Nicolas Sebrecht","Santi Béjar","Alex Riesen","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"102690","messageId":"20090131111011.GA29748@ultras","threadId":"17472","inReplyTo":null,"subject":"understanding index","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-01-31T11:10:11Z","receivedAt":"2009-01-31T11:10:11Z","isPatch":false,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"\nHey list.\n\nI'm having some understanding trouble with git index. As I understand,\n'git rm --cached' is not strictly the opposite of 'git add'. It's a\nlittle embarrassing in this particular case : what if you want to\ncommit and did a wrong 'git add -u' command ?\n\nHere's a minimalist sample :\n\n% ls\nfoo\tbar\n\n[ hack, hack, hack on both files ]\n\n% git status\n[...]\n\tmodified: foo\n\tmodified: bar\n[...]\n% git add -u foo bar\n\n[ optional hack on foo ]\n[ damn, you realize you don't want to commit changes on foo at all ]\n\n% git rm --cached foo\n% git status\n[...]\n\tdeleted: foo\n\tmodified: bar\n[...]\n\nIf committed as is, foo will be marked as deleted (in 'git log\n--name-status' at least, which is not wanted).\n\nHow to retrieve the state before the wrong 'git add -u' command _and_\nkeep the working tree as well (including last hacks) ? Is there any\ncommand which is the exact opposite of 'git add -u' ?\n\nCheers,\n\n-- \nNicolas Sebrecht\n"},{"id":"102691","messageId":"adf1fd3d0901310409y28dc493ak358749e0c29154cc@mail.gmail.com","threadId":"17472","inReplyTo":"20090131111011.GA29748@ultras","subject":"Re: understanding index","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2009-01-31T12:09:49Z","receivedAt":"2009-01-31T12:09:49Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:\n>\n> Hey list.\n>\n> I'm having some understanding trouble with git index. As I understand,\n> 'git rm --cached' is not strictly the opposite of 'git add'. It's a\n> little embarrassing in this particular case : what if you want to\n> commit and did a wrong 'git add -u' command ?\n>\n> Here's a minimalist sample :\n>\n> % ls\n> foo     bar\n>\n> [ hack, hack, hack on both files ]\n>\n> % git status\n> [...]\n>        modified: foo\n>        modified: bar\n> [...]\n> % git add -u foo bar\n>\n> [ optional hack on foo ]\n> [ damn, you realize you don't want to commit changes on foo at all ]\n>\n\nYou omitted the help message of git status, where it says how to unstage:\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n\nSo to not commit foo at all:\n\ngit reset HEAD foo\n\nHTH,\nSanti\n> % git rm --cached foo\n> % git status\n> [...]\n>        deleted: foo\n>        modified: bar\n> [...]\n>\n> If committed as is, foo will be marked as deleted (in 'git log\n> --name-status' at least, which is not wanted).\n>\n> How to retrieve the state before the wrong 'git add -u' command _and_\n> keep the working tree as well (including last hacks) ? Is there any\n> command which is the exact opposite of 'git add -u' ?\n>\n> Cheers,\n>\n> --\n> Nicolas Sebrecht\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"102702","messageId":"81b0412b0901310645t4307f67vf546e9c1c8c07701@mail.gmail.com","threadId":"17472","inReplyTo":"adf1fd3d0901310409y28dc493ak358749e0c29154cc@mail.gmail.com","subject":"Re: understanding index","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-01-31T14:45:29Z","receivedAt":"2009-01-31T14:45:29Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/1/31 Santi Béjar <santi@agolina.net>:\n> 2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:\n>> I'm having some understanding trouble with git index. As I understand,\n>> 'git rm --cached' is not strictly the opposite of 'git add'. It's a\n>> little embarrassing in this particular case : what if you want to\n>> commit and did a wrong 'git add -u' command ?\n>>\n> So to not commit foo at all:\n>\n> git reset HEAD foo\n>\n\nOr look at git gui, which allows you to select the not-to-commit parts visually\n"},{"id":"102709","messageId":"20090131201920.GC29748@ultras","threadId":"17472","inReplyTo":"adf1fd3d0901310409y28dc493ak358749e0c29154cc@mail.gmail.com","subject":"Re: understanding index","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-01-31T20:19:20Z","receivedAt":"2009-01-31T20:19:20Z","isPatch":false,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"\nOn Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:\n\n> You omitted the help message of git status, where it says how to unstage:\n> # Changes to be committed:\n> #   (use \"git reset HEAD <file>...\" to unstage)\n> \n> So to not commit foo at all:\n> \n> git reset HEAD foo\n\nThanks. I didn't omitted the help message of git status. The \"unstage\"\naction is what I was looking for but I was wrongly presuming (and I've\nread git docs !) that 'HEAD' is a kind of shortcut to the last commit of\nthe current branch (not to the last state of the working tree).\n\nWorking on branch master for example, we have in .git/HEAD :\nref: refs/heads/master\nAnd in .git/refs/heads/master, the hash of the last commit of branch\nmaster.\n\nI'm missing something here. But what ?\n\n-- \nNicolas Sebrecht\n"},{"id":"102711","messageId":"adf1fd3d0901311257j1501d222nc24514b013bd13f3@mail.gmail.com","threadId":"17472","inReplyTo":"20090131201920.GC29748@ultras","subject":"Re: understanding index","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2009-01-31T20:57:29Z","receivedAt":"2009-01-31T20:57:29Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:\n>\n> On Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:\n>\n>> You omitted the help message of git status, where it says how to unstage:\n>> # Changes to be committed:\n>> #   (use \"git reset HEAD <file>...\" to unstage)\n>>\n>> So to not commit foo at all:\n>>\n>> git reset HEAD foo\n>\n> Thanks. I didn't omitted the help message of git status.\n\nThese help messages (helpful messages?) were not in old version, but\nin current git you get this indications when you execute \"git status\",\nand it was what you put as \"[...]\".\n\n$ git status\n# On branch next\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#\tmodified:   Makefile\n#\n# Changed but not updated:\n#   (use \"git add <file>...\" to update what will be committed)\n#\n#\tmodified:   Makefile\n#\n\n\n> The \"unstage\"\n> action is what I was looking for but I was wrongly presuming (and I've\n> read git docs !) that 'HEAD' is a kind of shortcut to the last commit of\n> the current branch (not to the last state of the working tree).\n\nBy default git reset only acts on the head of the branch and the index, so with:\n\ngit reset HEAD foo\n\nwhat you are saying is, use the HEAD as the head of the branch (don't\nchange my branch), but put in the index the state of foo in HEAD, so\nin brief reset the index state of foo.\n>\n> Working on branch master for example, we have in .git/HEAD :\n> ref: refs/heads/master\n> And in .git/refs/heads/master, the hash of the last commit of branch\n> master.\n\nRight.\n\nHTH,\nSanti\n"},{"id":"102713","messageId":"20090131211800.GA30645@atjola.homenet","threadId":"17472","inReplyTo":"20090131201920.GC29748@ultras","subject":"Re: understanding index","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-01-31T21:18:00Z","receivedAt":"2009-01-31T21:18:00Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.01.31 21:19:20 +0100, Nicolas Sebrecht wrote:\n> \n> On Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:\n> \n> > You omitted the help message of git status, where it says how to unstage:\n> > # Changes to be committed:\n> > #   (use \"git reset HEAD <file>...\" to unstage)\n> > \n> > So to not commit foo at all:\n> > \n> > git reset HEAD foo\n> \n> Thanks. I didn't omitted the help message of git status. The \"unstage\"\n> action is what I was looking for but I was wrongly presuming (and I've\n> read git docs !) that 'HEAD' is a kind of shortcut to the last commit of\n> the current branch (not to the last state of the working tree).\n> \n> Working on branch master for example, we have in .git/HEAD :\n> ref: refs/heads/master\n> And in .git/refs/heads/master, the hash of the last commit of branch\n> master.\n> \n> I'm missing something here. But what ?\n\nYou're missing the fact that you want to reset the index entry to the\nstate from HEAD. The working tree state is the modified one, and you get\nthat into the index using \"git add\". But you want the index entry to be\nback at the state from HEAD. So HEAD is what you need to pass to reset\n(well, actually, you can skip \"HEAD\" there, it's the default).\n\nBjörn\n"},{"id":"102725","messageId":"20090131220712.GE29748@ultras","threadId":"17472","inReplyTo":"adf1fd3d0901311257j1501d222nc24514b013bd13f3@mail.gmail.com","subject":"Re: understanding index","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-01-31T22:07:12Z","receivedAt":"2009-01-31T22:07:12Z","isPatch":false,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"\nOn Sat, Jan 31, 2009 at 09:57:29PM +0100, Santi Béjar wrote:\n\n> By default git reset only acts on the head of the branch and the index, so with:\n> \n> git reset HEAD foo\n> \n> what you are saying is, use the HEAD as the head of the branch (don't\n> change my branch), but put in the index the state of foo in HEAD, so\n> in brief reset the index state of foo.\n\nThank you all for the explanations.\n\n-- \nNicolas Sebrecht\n"}]}