{"thread":{"id":"26512","subject":"non-empty index with git commit -a","startedAt":"2011-02-15T22:43:53Z","lastAt":"2011-02-16T22:34:51Z","messageCount":25,"participants":["Sverre Rabbelier","Jeff King","Jonathan Nieder","Nguyen Thai Ngoc Duy","Matthieu Moy","Michael J Gruber","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161227","messageId":"AANLkTi=5E8D0mwMDNuMdgZS69kOnKCfs=Q8X5bpcjnYF@mail.gmail.com","threadId":"26512","inReplyTo":null,"subject":"non-empty index with git commit -a","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-15T22:43:53Z","receivedAt":"2011-02-15T22:43:53Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nCan we please fix this?\n\n$ hack hack hack\n$ git add -p # carefully add my changes\n$ git commit -am \"Add feature foo\"\n$ DAAAMN YOUUU FINGERS!!\n\nI remember bringing this up before, but I can't remember what the\ndiscussion ended up coming to.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161250","messageId":"20110216023645.GA7085@sigill.intra.peff.net","threadId":"26512","inReplyTo":"AANLkTi=5E8D0mwMDNuMdgZS69kOnKCfs=Q8X5bpcjnYF@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T02:36:46Z","receivedAt":"2011-02-16T02:36:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 15, 2011 at 10:43:53PM +0000, Sverre Rabbelier wrote:\n\n> Can we please fix this?\n> \n> $ hack hack hack\n> $ git add -p # carefully add my changes\n> $ git commit -am \"Add feature foo\"\n> $ DAAAMN YOUUU FINGERS!!\n> \n> I remember bringing this up before, but I can't remember what the\n> discussion ended up coming to.\n\nHow do you differentiate this from:\n\n  $ hack hack hack\n  $ git add -p ;# carefully add my changes\n  $ hack hack hack\n  $ git diff ;# ok, everything looks good\n  $ git commit -am \"Add feature foo\"\n\n? IOW, I don't think git can know that you are making a mistake in your\ncase, since from its perspectives those same actions might be\nreasonable. The real problem is that your intermediate index state is\nnever saved. Do we need an index reflog? :)\n\n-Peff\n"},{"id":"161255","messageId":"20110216032047.GA2858@elie","threadId":"26512","inReplyTo":"20110216023645.GA7085@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-16T03:20:47Z","receivedAt":"2011-02-16T03:20:47Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Tue, Feb 15, 2011 at 10:43:53PM +0000, Sverre Rabbelier wrote:\n\n>> Can we please fix this?\n>>\n>> $ hack hack hack\n>> $ git add -p # carefully add my changes\n>> $ git commit -am \"Add feature foo\"\n>> $ DAAAMN YOUUU FINGERS!!\n>>\n>> I remember bringing this up before, but I can't remember what the\n>> discussion ended up coming to.\n>\n> How do you differentiate this from:\n>\n>   $ hack hack hack\n>   $ git add -p ;# carefully add my changes\n>   $ hack hack hack\n>   $ git diff ;# ok, everything looks good\n>   $ git commit -am \"Add feature foo\"\n>\n> ?\n\nIf I remember the discussion[1] correctly, by requiring a separate\nadd -u step (or commit -f -a) if the \"I don't trust my fingers\"\nconfiguration is enabled.\n\n[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145662\n"},{"id":"161256","messageId":"20110216032715.GA1666@sigill.intra.peff.net","threadId":"26512","inReplyTo":"20110216032047.GA2858@elie","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T03:27:15Z","receivedAt":"2011-02-16T03:27:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 15, 2011 at 09:20:47PM -0600, Jonathan Nieder wrote:\n\n> Jeff King wrote:\n> > On Tue, Feb 15, 2011 at 10:43:53PM +0000, Sverre Rabbelier wrote:\n> \n> >> Can we please fix this?\n> >>\n> >> $ hack hack hack\n> >> $ git add -p # carefully add my changes\n> >> $ git commit -am \"Add feature foo\"\n> >> $ DAAAMN YOUUU FINGERS!!\n> >>\n> >> I remember bringing this up before, but I can't remember what the\n> >> discussion ended up coming to.\n> >\n> > How do you differentiate this from:\n> >\n> >   $ hack hack hack\n> >   $ git add -p ;# carefully add my changes\n> >   $ hack hack hack\n> >   $ git diff ;# ok, everything looks good\n> >   $ git commit -am \"Add feature foo\"\n> >\n> > ?\n> \n> If I remember the discussion[1] correctly, by requiring a separate\n> add -u step (or commit -f -a) if the \"I don't trust my fingers\"\n> configuration is enabled.\n> \n> [1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145662\n\nThanks for the link, I didn't recall that discussion. I have no problem\nwith a config option that requires an extra step, but such a safety\nvalve should definitely be optional, since the current behavior is part\nof a perfectly reasonable workflow.\n\n-Peff\n"},{"id":"161265","messageId":"AANLkTinbcHW+ja7T=PiCEorNdnK6W2DvA_c9F8JTEMKB@mail.gmail.com","threadId":"26512","inReplyTo":"20110216032047.GA2858@elie","subject":"Re: non-empty index with git commit -a","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-16T08:18:18Z","receivedAt":"2011-02-16T08:18:18Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Feb 16, 2011 at 03:20, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> If I remember the discussion[1] correctly, by requiring a separate\n> add -u step (or commit -f -a) if the \"I don't trust my fingers\"\n> configuration is enabled.\n\nThat would definitely work for me. The question then is, should git\nconsider the index precious by default, or not? That is, should that\nvalue default to true in 1.8?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161266","messageId":"AANLkTikmxHQpir5YbiBihASL1SYf_AyoUHKT3nqKS-iP@mail.gmail.com","threadId":"26512","inReplyTo":"AANLkTinbcHW+ja7T=PiCEorNdnK6W2DvA_c9F8JTEMKB@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-16T08:29:19Z","receivedAt":"2011-02-16T08:29:19Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 16, 2011 at 3:18 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> Heya,\n>\n> On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>> If I remember the discussion[1] correctly, by requiring a separate\n>> add -u step (or commit -f -a) if the \"I don't trust my fingers\"\n>> configuration is enabled.\n>\n> That would definitely work for me. The question then is, should git\n> consider the index precious by default, or not? That is, should that\n> value default to true in 1.8?\n\nIs it insane that \"git commit -a\" still commits everything, but then\n\n1. If old index is different from old HEAD, keeps index as is and warn users\n2. If old index is the same as old HEAD, update index with new HEAD\n\n?\n-- \nDuy\n"},{"id":"161267","messageId":"20110216084452.GC3345@elie","threadId":"26512","inReplyTo":"AANLkTikmxHQpir5YbiBihASL1SYf_AyoUHKT3nqKS-iP@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-16T08:44:53Z","receivedAt":"2011-02-16T08:44:53Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> On Wed, Feb 16, 2011 at 3:18 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n>> On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>>> If I remember the discussion[1] correctly, by requiring a separate\n>>> add -u step (or commit -f -a) if the \"I don't trust my fingers\"\n>>> configuration is enabled.\n>>\n>> That would definitely work for me. The question then is, should git\n>> consider the index precious by default, or not? That is, should that\n>> value default to true in 1.8?\n>\n> Is it insane that \"git commit -a\" still commits everything, but then\n>\n> 1. If old index is different from old HEAD, keeps index as is and warn users\n> 2. If old index is the same as old HEAD, update index with new HEAD\n>\n> ?\n\nYes, I think that would be very confusing. :)\n\nMy take on Sverre's question: this doesn't seem to fit the \"bad choice\nmade long ago and finally we have a chance to fix it\" mold.  More like\n\"nice new feature that could break muscle memory\".  So I don't think\nit makes sense to tie it to 1.8.\n\nIf I were writing the patch, I'd provide the configuration and hope\nthat the experience of using it could help with deciding on a good\ndefault behavior.\n"},{"id":"161268","messageId":"20110216085114.GA9413@sigill.intra.peff.net","threadId":"26512","inReplyTo":"AANLkTinbcHW+ja7T=PiCEorNdnK6W2DvA_c9F8JTEMKB@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T08:51:14Z","receivedAt":"2011-02-16T08:51:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 08:18:18AM +0000, Sverre Rabbelier wrote:\n\n> On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> > If I remember the discussion[1] correctly, by requiring a separate\n> > add -u step (or commit -f -a) if the \"I don't trust my fingers\"\n> > configuration is enabled.\n> \n> That would definitely work for me. The question then is, should git\n> consider the index precious by default, or not? That is, should that\n> value default to true in 1.8?\n\nIf we do not consider the index precious, then no, it should not be the\ndefault. If we do consider it precious, then isn't this option fixing\none small case and leaving all of the others untouched?\n\nI can just as easily run \"git add -u\", or \"git add -p\" on top of some\nchanges and then realize afterwards that I actually wanted the previous\nindex state.\n\nThe solution for that would be an index reflog.\n\n-Peff\n"},{"id":"161270","messageId":"vpqsjvos61w.fsf@bauges.imag.fr","threadId":"26512","inReplyTo":"20110216032047.GA2858@elie","subject":"Re: non-empty index with git commit -a","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-16T09:05:31Z","receivedAt":"2011-02-16T09:05:31Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> If I remember the discussion[1] correctly, by requiring a separate\n> add -u step (or commit -f -a) if the \"I don't trust my fingers\"\n> configuration is enabled.\n>\n> [1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145662\n\nYou may want to look at what eg (easy git) does too:\n\nhttp://people.gnome.org/~newren/eg/documentation/commit.html\n\nessentially, it considers commiting with dirty index the uncommon\ncase, and requires an extra --staged flag to allow it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"161276","messageId":"AANLkTik_F=d1CjNVfj35wgv0pL1LefOMnttXjs=s2wCQ@mail.gmail.com","threadId":"26512","inReplyTo":"20110216085114.GA9413@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-16T09:52:23Z","receivedAt":"2011-02-16T09:52:23Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Feb 16, 2011 at 08:51, Jeff King <peff@peff.net> wrote:\n> I can just as easily run \"git add -u\", or \"git add -p\" on top of some\n> changes and then realize afterwards that I actually wanted the previous\n> index state.\n\nI disagree, those are all index manipulation tools, `git commit -a` is not.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161277","messageId":"20110216095415.GA12578@sigill.intra.peff.net","threadId":"26512","inReplyTo":"AANLkTik_F=d1CjNVfj35wgv0pL1LefOMnttXjs=s2wCQ@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T09:54:15Z","receivedAt":"2011-02-16T09:54:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 09:52:23AM +0000, Sverre Rabbelier wrote:\n\n> On Wed, Feb 16, 2011 at 08:51, Jeff King <peff@peff.net> wrote:\n> > I can just as easily run \"git add -u\", or \"git add -p\" on top of some\n> > changes and then realize afterwards that I actually wanted the previous\n> > index state.\n> \n> I disagree, those are all index manipulation tools, `git commit -a` is not.\n\nSo? Your question was whether index state is precious. If it's precious,\nshouldn't we be keeping a history of it?\n\n-Peff\n"},{"id":"161278","messageId":"AANLkTimj9NCR2Kkiz82WW1qx1NY-ptS4Qn2yzPqoLGP0@mail.gmail.com","threadId":"26512","inReplyTo":"20110216095415.GA12578@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-16T09:58:52Z","receivedAt":"2011-02-16T09:58:52Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:\n> So? Your question was whether index state is precious. If it's precious,\n> shouldn't we be keeping a history of it?\n\nI don't think it's quite _that_ precious, but the only operation that\nI regularly use that can blow away my carefully constructed index as\nside effect of doing something else is `git commit -a`.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"161279","messageId":"20110216100622.GA12971@sigill.intra.peff.net","threadId":"26512","inReplyTo":"AANLkTimj9NCR2Kkiz82WW1qx1NY-ptS4Qn2yzPqoLGP0@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T10:06:34Z","receivedAt":"2011-02-16T10:06:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:\n\n> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:\n> > So? Your question was whether index state is precious. If it's precious,\n> > shouldn't we be keeping a history of it?\n> \n> I don't think it's quite _that_ precious, but the only operation that\n> I regularly use that can blow away my carefully constructed index as\n> side effect of doing something else is `git commit -a`.\n\nOK, so how precious is it? :)\n\nIf you want to have an option that specifically prevents the \"git commit\n-a\" muscle memory thing, then go for it. I'm guessing it is the most\ncommon \"oops\" one. Even with an index reflog, you might want it on top.\n\nBut it just seems silly to me to not protect at the same time against\nthe other ways you can lose state from the index.\n\n-Peff\n"},{"id":"161286","messageId":"vpqbp2cmfy6.fsf@bauges.imag.fr","threadId":"26512","inReplyTo":"20110216095415.GA12578@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-16T10:28:17Z","receivedAt":"2011-02-16T10:28:17Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> So? Your question was whether index state is precious. If it's precious,\n> shouldn't we be keeping a history of it?\n\nIf it's really precious, it probably means you should be commit\n--amend instead. You'd get the reflog, and essentially the same\nfunctionalities.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"161303","messageId":"4D5BE21F.7020106@drmicha.warpmail.net","threadId":"26512","inReplyTo":"20110216100622.GA12971@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-16T14:41:35Z","receivedAt":"2011-02-16T14:41:35Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 16.02.2011 11:06:\n> On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:\n> \n>> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:\n>>> So? Your question was whether index state is precious. If it's precious,\n>>> shouldn't we be keeping a history of it?\n>>\n>> I don't think it's quite _that_ precious, but the only operation that\n>> I regularly use that can blow away my carefully constructed index as\n>> side effect of doing something else is `git commit -a`.\n> \n> OK, so how precious is it? :)\n\nMaybe it's a bit precious, but not overly...\n\n> \n> If you want to have an option that specifically prevents the \"git commit\n> -a\" muscle memory thing, then go for it. I'm guessing it is the most\n> common \"oops\" one. Even with an index reflog, you might want it on top.\n> \n> But it just seems silly to me to not protect at the same time against\n> the other ways you can lose state from the index.\n> \n> -Peff\n\nso that keeping one backup would be enough? I.e. an automated way of\ndoing \"cp index index.bak\" before an index update and some \"reset\"\nincarnation to revive the copy?\n\nMichael\n"},{"id":"161320","messageId":"7vtyg3ke9m.fsf@alter.siamese.dyndns.org","threadId":"26512","inReplyTo":"AANLkTik_F=d1CjNVfj35wgv0pL1LefOMnttXjs=s2wCQ@mail.gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T18:47:33Z","receivedAt":"2011-02-16T18:47:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Wed, Feb 16, 2011 at 08:51, Jeff King <peff@peff.net> wrote:\n>> I can just as easily run \"git add -u\", or \"git add -p\" on top of some\n>> changes and then realize afterwards that I actually wanted the previous\n>> index state.\n>\n> I disagree, those are all index manipulation tools, `git commit -a` is not.\n\n\"git commmit\" is not an index-manipulation tool.  Giving \"-a\" or pathspec\nto the command however is.\n\nHaving said that, exactly because \"commit\" _feels_ more like a\npoint-of-no-return than a mistaken second \"add\" to the end user (even\nthough it is not technically different), I think it is Ok to add a\nconfiguration that makes the command bail out when \"-a\" is given and there\nare changes to the index.  I don't think it is sane to trigger the same\nsafety when a pathspec is given, though.\n"},{"id":"161321","messageId":"7vpqqrke30.fsf@alter.siamese.dyndns.org","threadId":"26512","inReplyTo":"20110216100622.GA12971@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T18:51:31Z","receivedAt":"2011-02-16T18:51:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:\n>\n>> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:\n>> > So? Your question was whether index state is precious. If it's precious,\n>> > shouldn't we be keeping a history of it?\n>> \n>> I don't think it's quite _that_ precious, but the only operation that\n>> I regularly use that can blow away my carefully constructed index as\n>> side effect of doing something else is `git commit -a`.\n>\n> OK, so how precious is it? :)\n\nThe world is not that black-and-white, but is full of different shades of\ngray.\n\nIf you made mistakes with a second \"git add\", you can \"reset --mixed\"\neverything away and restart from scratch.  The same thing can be said for\na mistaken \"git commit -a\" that can be \"reset HEAD^\" (or --amend).  So\nthere is not much difference at the technical level.\n\nI don't think this is primarily about \"protecting the index\".  It is more\nabout making the user feel better.  Compared to a mistaken second \"add\", a\nmistaken \"commit -a\" feels like a lot heavier point-of-no-return.\n"},{"id":"161326","messageId":"20110216192904.GA22045@sigill.intra.peff.net","threadId":"26512","inReplyTo":"4D5BE21F.7020106@drmicha.warpmail.net","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T19:29:04Z","receivedAt":"2011-02-16T19:29:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 03:41:35PM +0100, Michael J Gruber wrote:\n\n> > If you want to have an option that specifically prevents the \"git commit\n> > -a\" muscle memory thing, then go for it. I'm guessing it is the most\n> > common \"oops\" one. Even with an index reflog, you might want it on top.\n> > \n> > But it just seems silly to me to not protect at the same time against\n> > the other ways you can lose state from the index.\n> > \n> so that keeping one backup would be enough? I.e. an automated way of\n> doing \"cp index index.bak\" before an index update and some \"reset\"\n> incarnation to revive the copy?\n\nNo, I am not proposing one backup. I am proposing a reflog with multiple\nentries that would be expired on the regular reflog schedule.\n\n-Peff\n"},{"id":"161328","messageId":"20110216193643.GB22045@sigill.intra.peff.net","threadId":"26512","inReplyTo":"7vpqqrke30.fsf@alter.siamese.dyndns.org","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T19:36:43Z","receivedAt":"2011-02-16T19:36:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 10:51:31AM -0800, Junio C Hamano wrote:\n\n> > OK, so how precious is it? :)\n> \n> The world is not that black-and-white, but is full of different shades of\n> gray.\n> \n> If you made mistakes with a second \"git add\", you can \"reset --mixed\"\n> everything away and restart from scratch.  The same thing can be said for\n> a mistaken \"git commit -a\" that can be \"reset HEAD^\" (or --amend).  So\n> there is not much difference at the technical level.\n\nSure. The problem there is that \"scratch\" may involve losing some work\nyou did picking apart changes.\n\n> I don't think this is primarily about \"protecting the index\".  It is more\n> about making the user feel better.  Compared to a mistaken second \"add\", a\n> mistaken \"commit -a\" feels like a lot heavier point-of-no-return.\n\nI guess. I have very occasionally run into the second-add problem and\nwanted to be able to return to an earlier index state, but I admit it\ndoesn't come up that much. I just see them as the same problem.\n\nI think I am also a little turned off by the config option solution\nbecause it seems very un-git to me. Our usual approach is to give the\nuser a lot of flexibility, let them shoot their own foot off, and then\nlet them know that their intact foot is waiting in the reflog, ready to\nbe sewn back on.\n\nYes, we try to limit uselessly destructive actions before they happen.\nBut this is not one of those cases. The exact command set that is being\nlisted as dangerous is also part of a very reasonable workflow. It just\ndepends on what the user's intention was.\n\nBut as I said, I am not against a config option if it is such a common\nproblem. I certainly would not turn it on. And I don't think it should\nbe on by default.\n\n-Peff\n"},{"id":"161329","messageId":"20110216194855.GC22045@sigill.intra.peff.net","threadId":"26512","inReplyTo":"vpqbp2cmfy6.fsf@bauges.imag.fr","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T19:48:55Z","receivedAt":"2011-02-16T19:48:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 11:28:17AM +0100, Matthieu Moy wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > So? Your question was whether index state is precious. If it's precious,\n> > shouldn't we be keeping a history of it?\n> \n> If it's really precious, it probably means you should be commit\n> --amend instead. You'd get the reflog, and essentially the same\n> functionalities.\n\nYeah, that is good advice, and I do actually end up doing a lot of\nintermediate commits and then either amending or sorting them out at the\nend. And that helps with sorting out big changes.\n\nBut it does sort of feel like saying \"we don't need a safety valve. You\njust need to back up your work before doing anything dangerous\". I have\nto remember to do it. Which is fine if my workflow is\nadd-amend-add-amend. But maybe I have some half-saved index state and I\nam about to try doing a merge checkout or stash apply.\n\nAnyway, I'm not convinced it is all that precious (at least not enough\nto merit working on the reflog). Yes, there have been times I've wished\nI could go back to the index state of a minute ago, and had to re-sort\nchanges. But it usually doesn't take all that much time (thanks to \"git\nadd -p\"). My main objection is that I just don't see those cases as\ndifferent from \"git commit -a\". Either it is worth protecting, or it\nisn't.\n\n-Peff\n"},{"id":"161331","messageId":"7v1v37kb3p.fsf@alter.siamese.dyndns.org","threadId":"26512","inReplyTo":"20110216193643.GB22045@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T19:55:54Z","receivedAt":"2011-02-16T19:55:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> But as I said, I am not against a config option if it is such a common\n> problem. I certainly would not turn it on. And I don't think it should\n> be on by default.\n\nI think we are pretty much on the same page, except that I am not very\ninterested in the index-log either.\n"},{"id":"161332","messageId":"20110216195931.GA22884@sigill.intra.peff.net","threadId":"26512","inReplyTo":"7v1v37kb3p.fsf@alter.siamese.dyndns.org","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T19:59:31Z","receivedAt":"2011-02-16T19:59:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 11:55:54AM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > But as I said, I am not against a config option if it is such a common\n> > problem. I certainly would not turn it on. And I don't think it should\n> > be on by default.\n> \n> I think we are pretty much on the same page, except that I am not very\n> interested in the index-log either.\n\nTo be fair, I am not sure I am that interested in the index-log either.\nI just see it as a superior solution to the same problem, but I don't\nconsider it a very important problem.\n\nSo I think we are really on the same page. :)\n\n-Peff\n"},{"id":"161335","messageId":"201102162203.40480.jnareb@gmail.com","threadId":"26512","inReplyTo":"20110216195931.GA22884@sigill.intra.peff.net","subject":"Re: non-empty index with git commit -a","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-16T21:03:31Z","receivedAt":"2011-02-16T21:03:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 16. lutego 2011 20:59, Jeff King napisał:\n> On Wed, Feb 16, 2011 at 11:55:54AM -0800, Junio C Hamano wrote:\n> \n> > Jeff King <peff@peff.net> writes:\n> > \n> > > But as I said, I am not against a config option if it is such a common\n> > > problem. I certainly would not turn it on. And I don't think it should\n> > > be on by default.\n> > \n> > I think we are pretty much on the same page, except that I am not very\n> > interested in the index-log either.\n> \n> To be fair, I am not sure I am that interested in the index-log either.\n> I just see it as a superior solution to the same problem, but I don't\n> consider it a very important problem.\n> \n> So I think we are really on the same page. :)\n\nAlso it would be not as easy as reflogs - you would have either to save\ncopy of index, or create a tree out of it and save reference in reflog.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"161344","messageId":"7v39nnirfq.fsf@alter.siamese.dyndns.org","threadId":"26512","inReplyTo":"201102162203.40480.jnareb@gmail.com","subject":"Re: non-empty index with git commit -a","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T21:46:01Z","receivedAt":"2011-02-16T21:46:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n>> So I think we are really on the same page. :)\n>\n> Also it would be not as easy as reflogs - you would have either to save\n> copy of index, or create a tree out of it and save reference in reflog.\n\nAlso note that \"Create a tree out of it\" is not always a useful way to\nsave the state of the index.  The \"stash\" shares the same issue, but you\nwould need an equivalent of a tarball that consists of the index file\n(with conflicted state) and the files in the working tree that corresponds\nto index entries with conflicted states if you want to be useful for\nstoring a state away in case you botch the conflict resolution you are\nattempting.\n"},{"id":"161350","messageId":"20110216223450.GA5617@sigill.intra.peff.net","threadId":"26512","inReplyTo":"7v39nnirfq.fsf@alter.siamese.dyndns.org","subject":"Re: non-empty index with git commit -a","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T22:34:51Z","receivedAt":"2011-02-16T22:34:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 16, 2011 at 01:46:01PM -0800, Junio C Hamano wrote:\n\n> > Also it would be not as easy as reflogs - you would have either to save\n> > copy of index, or create a tree out of it and save reference in reflog.\n> \n> Also note that \"Create a tree out of it\" is not always a useful way to\n> save the state of the index.  The \"stash\" shares the same issue, but you\n> would need an equivalent of a tarball that consists of the index file\n> (with conflicted state) and the files in the working tree that corresponds\n> to index entries with conflicted states if you want to be useful for\n> storing a state away in case you botch the conflict resolution you are\n> attempting.\n\nI had assumed it would be a reflog of trees (or more likely parentless\ncommits), just keeping track of useful states. But the usage there isn't\nvery intuitive. You can do \"git show index@{5.minutes.ago}:foo.c >bar.c\"\nto recover the state of a file, or even \"git read-tree index@{1}\" to\nget a whole state. And those would be enough for the basic \"oops, I just\nwant to go back to where I was\".\n\nBut probably you should be able to do a three-way merge with where you\nare now, with the HEAD at the time of save as a pseudo-parent. IOW,\ntreat the index state as if you had committed it and put it on a reflog.\nAnd in the case that you are at the same HEAD, then a merge collapses\ninto a \"fast-forward\" to the index state you were at (I put\n\"fast-forward\" in quotes because we are obviously not interested in\nmoving HEAD to the pseudo-commit at all, but just what ends up in the\nindex).\n\nI dunno. I haven't thought all that hard about it, so maybe there is a\nmore clever way of doing it. Certainly the porcelain support for \"reset\nto this index, but don't move my HEAD\" is not good, nor for \"merge this\nindex, but nevermind about recording anything about the commit\".  They\nare both conceptually easy to implement in terms of plumbing, but the\ncommands to run them are a little unintuitive.\n\n-Peff\n"}]}