{"thread":{"id":"44332","subject":"tools for easily \"uncommitting\" parts of a patch I just commited?","startedAt":"2016-10-19T22:26:46Z","lastAt":"2016-10-23T10:28:23Z","messageCount":16,"participants":["Jacob Keller","Jeff King","Junio C Hamano","Lukas Fleischer","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"304432","messageId":"CA+P7+xqFOn4NSfZ2zpa_y1za3uHZrGGG3ktEtuOcvJLCrAYUhQ@mail.gmail.com","threadId":"44332","inReplyTo":null,"subject":"tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-19T22:26:18Z","receivedAt":"2016-10-19T22:26:46Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"Hi,\n\nI recently (and in the past) had an issue where I was using git add\n--interactive and accidentally did something like the following:\n\n# hack lots of randmo changes, then begin trying to commit then separately\ngit add -i\n# set only the changes I want\n# accidentally add to the commit\n$git commit -s \n# type up a long commit message\n# notice that I committed everything\n\nAt this point I'd like to be able to do something like:\n$git unstage -i\n# select each hunk to unstage\n\nand end up with a commit that only has what I originally wanted,\nwithout having to re-write the commit message, nor having to do a lot\nof weird things, or anything.\n\nI can ofcourse use reset HEAD^ and lose my commit message, but then\nI'd have to retype that out or copy paste it from somewhere else.\n\nI ended up doing something like:\n\n# save the current tree\n$git rev-parse HEAD >savetree\n# checkout the old files and re-write\n$git checkout HEAD^ \n# update commit removing all changes from this file\n$git commit --allow-empty --amend \n# now checkout the tree again to the contents of the saved tree\n$git checkout $(cat savetree) \n# now add only the parts I wanted before\n$git add -i\n# finally amend the commit\n$git commit --amend\n\nThat's a lot of steps and forces me to save my own file.\n\nI thought of a few alternatives:\n\n1. Create an advice setting which basically allows me to say \"git,\nplease prevent me from staging files + an index if the files I marked\nalso conflict with paths already added to the index, maybe unless I\npassed a force option\"\n\nor\n\n2. somehow streamline the process of what I did above so I could just\ndo something like:\n\ngit commit --amend --set-tree=HEAD^\n\nwhich would force the commit tree up one and avoid the double checkout\nstuff, without actually changing my checked out copy at all\n\nThen I'd be able to quickly re-add what I wanted.\n\n\n3. somehow allow an unstage option.\n\nSo for the TL;DR; .. does anyone know of any tools which would help\nautomate the process so I could simply do\n\n\"git uncommit -i\" and run a tool just like git add interactive or git add -p?\n\nThanks,\nJake\n"},{"id":"304439","messageId":"20161019224211.k4anavgqrhmunz6p@sigill.intra.peff.net","threadId":"44332","inReplyTo":"CA+P7+xqFOn4NSfZ2zpa_y1za3uHZrGGG3ktEtuOcvJLCrAYUhQ@mail.gmail.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-19T22:42:11Z","receivedAt":"2016-10-19T22:42:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote:\n\n> I recently (and in the past) had an issue where I was using git add\n> --interactive and accidentally did something like the following:\n> \n> # hack lots of randmo changes, then begin trying to commit then separately\n> git add -i\n> # set only the changes I want\n> # accidentally add to the commit\n> $git commit -s \n> # type up a long commit message\n> # notice that I committed everything\n> \n> At this point I'd like to be able to do something like:\n> $git unstage -i\n> # select each hunk to unstage\n\nI'd usually do one of:\n\n # undo selectively\n git reset -p HEAD^\n git commit --amend\n\nor:\n\n # roll back the whole commit\n git reset HEAD\n # do it right this time\n git add -p\n # and steal the commit message from the previous attempt\n git commit -c HEAD@{1}\n\n-Peff\n"},{"id":"304442","messageId":"CA+P7+xprKV1Y7VShLR9uNgcpVdZk39xoTfkwiin1bVQYTe_TAA@mail.gmail.com","threadId":"44332","inReplyTo":"20161019224211.k4anavgqrhmunz6p@sigill.intra.peff.net","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-19T23:36:36Z","receivedAt":"2016-10-19T23:37:02Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Oct 19, 2016 at 3:42 PM, Jeff King wrote:\n> On Wed, Oct 19, 2016 at 03:26:18PM -0700, Jacob Keller wrote:\n>\n>> I recently (and in the past) had an issue where I was using git add\n>> --interactive and accidentally did something like the following:\n>>\n>> # hack lots of randmo changes, then begin trying to commit then separately\n>> git add -i\n>> # set only the changes I want\n>> # accidentally add to the commit\n>> $git commit -s \n>> # type up a long commit message\n>> # notice that I committed everything\n>>\n>> At this point I'd like to be able to do something like:\n>> $git unstage -i\n>> # select each hunk to unstage\n>\n> I'd usually do one of:\n>\n> # undo selectively\n> git reset -p HEAD^\n> git commit --amend\n\nAHA! I knew about git reset -p but I didn't know about git reset -p\nallowed passing a treeish. Does this reset modify my local files at\nall? I think it doesn't, right?\n\n>\n> or:\n>\n> # roll back the whole commit\n> git reset HEAD\n> # do it right this time\n> git add -p\n> # and steal the commit message from the previous attempt\n> git commit -c HEAD@{1}\n>\n> -Peff\n\nAlso nice to know about git commit -c\n\nThanks a lot! This should save me some headaches.\n\nI still think it's worth while to add a check for git-commit which\ndoes something like check when we say \"git commit \" and if the\nindex already has those files marked as being changed, compare them\nwith the current contents of the file as in the checkout and quick\nsaying \"please don't do that\" so as to avoid the problem in the first\nplace.\n\nA naive approach would just be \"if index already has staged\ndifferences dont allow path selection\" but that doesn't let me do\nsomething like \"git add -p \" \"git commit \"\n\nWe could even make it work so that \"commit --only\" doesn't run this so\nthat way people can easily override, and we can give suggestions for\nhow to fix it in the output of the message. I can't really think if a\nreasonable objection to such a change. I'll try to code something up\nin the next few days when I can find some spare time.\n\nRegards,\nJake\n"},{"id":"304445","messageId":"20161020021323.tav5glu7xy4u7mtj@sigill.intra.peff.net","threadId":"44332","inReplyTo":"CA+P7+xprKV1Y7VShLR9uNgcpVdZk39xoTfkwiin1bVQYTe_TAA@mail.gmail.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-20T02:13:23Z","receivedAt":"2016-10-20T02:13:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 19, 2016 at 04:36:36PM -0700, Jacob Keller wrote:\n\n> > # undo selectively\n> > git reset -p HEAD^\n> > git commit --amend\n> \n> AHA! I knew about git reset -p but I didn't know about git reset -p\n> allowed passing a treeish. Does this reset modify my local files at\n> all? I think it doesn't, right?\n\nCorrect. If you wanted to modify the working tree, too, use \"git\ncheckout -p HEAD^\".\n\n> I still think it's worth while to add a check for git-commit which\n> does something like check when we say \"git commit \" and if the\n> index already has those files marked as being changed, compare them\n> with the current contents of the file as in the checkout and quick\n> saying \"please don't do that\" so as to avoid the problem in the first\n> place.\n> \n> A naive approach would just be \"if index already has staged\n> differences dont allow path selection\" but that doesn't let me do\n> something like \"git add -p \" \"git commit \"\n\nI suspect both of those would complain about legitimate workflows.\n\nI dunno. I do not ever use \"git commit \" myself. I almost\ninvariably use one of \"git add -p\" (to review changes as I add them) or\n\"git add -u\" (when I know everything is in good shape, such as after\nmerge resolution; I'll sometimes just \"git commit -a\", too).\n\nBut it sounds like you want a third mode besides \"--include\" and\n\"--only\". Basically \"commit what has been staged already, but restrict\nthe commit to the paths I mentioned\". Something like \"--only-staged\" or\nsomething. I do not think we would want to change the default from\n--only, but I could see a config option or something to select that\nbehavior.\n\nI suspect nobody has really asked for such a thing before because\nseparate staging and \"git commit \" are really two distinct\nworkflows. Your pain comes from mix-and-matching them.\n\n-Peff\n"},{"id":"304446","messageId":"CA+P7+xokV9CJ-XRyGn8yU7cinc+KvOfL3zMw4Dfdx4LxULSiHA@mail.gmail.com","threadId":"44332","inReplyTo":"20161020021323.tav5glu7xy4u7mtj@sigill.intra.peff.net","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-20T05:53:51Z","receivedAt":"2016-10-20T05:54:23Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Oct 19, 2016 at 7:13 PM, Jeff King wrote:\n> I suspect both of those would complain about legitimate workflows.\n>\n> I dunno. I do not ever use \"git commit \" myself. I almost\n> invariably use one of \"git add -p\" (to review changes as I add them) or\n> \"git add -u\" (when I know everything is in good shape, such as after\n> merge resolution; I'll sometimes just \"git commit -a\", too).\n>\n> But it sounds like you want a third mode besides \"--include\" and\n> \"--only\". Basically \"commit what has been staged already, but restrict\n> the commit to the paths I mentioned\". Something like \"--only-staged\" or\n> something. I do not think we would want to change the default from\n> --only, but I could see a config option or something to select that\n> behavior.\n>\n> I suspect nobody has really asked for such a thing before because\n> separate staging and \"git commit \" are really two distinct\n> workflows. Your pain comes from mix-and-matching them.\n>\n> -Peff\n\nNo. What I want is to *prevent* mix-and-match from happening.\nBasically, sometimes I use \"git add -p\" to stage changes. But if I\njust did a \"git diff\" and I know all the changes that I want are in\nthe file I will just do \"git commit \" or \"git commit -a\". The\nproblem is that sometimes I stage stuff, forget or just make a brain\nmistake, and I go ahead and use \"git commit \"\n\nWhat I want is to make it so that when you run \"git commit \"\nthat it is smart enough to go \"hey! You already staged something from\nthat file in the index and it doesn't match what you're asking me to\ncommit now, so I'm going to stop and make sure you either reset, don't\nrun \"git commit \" or run \"git commit --only \" or similar.\n\nIt's just about making it so that if I happen to make the mistake in\nthe future it doesn't generate a commit and instead tells me that I\nwas being an idiot. I don't want this check to just be \"you can't\nstage with the index and then tell me to commit -a or commit \"\nbecause I think that's too restrictive and might make people complain.\n\nEssentially, I want the tool to become smart enough to make it so that\nan obvious mistake is caught early before I have to undo things.\n\nThat being said, it's much less of a pain point now that I know I can\ngo \"git reset -p HEAD^\". It never occurred to me that git reset -p\nwould work that way, so I didn't even try it.\n\nThanks,\nJake\n"},{"id":"304476","messageId":"xmqqa8dzhtki.fsf@gitster.mtv.corp.google.com","threadId":"44332","inReplyTo":"20161020021323.tav5glu7xy4u7mtj@sigill.intra.peff.net","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-20T16:30:05Z","receivedAt":"2016-10-20T16:30:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> I still think it's worth while to add a check for git-commit which\n>> does something like check when we say \"git commit \" and if the\n>> index already has those files marked as being changed, compare them\n>> with the current contents of the file as in the checkout and quick\n>> saying \"please don't do that\" so as to avoid the problem in the first\n>> place.\n> ...\n> I suspect both of those would complain about legitimate workflows.\n>\n> I dunno. I do not ever use \"git commit \" myself.\n\nUsers are different. I do use this all the time, and it is not\nunusual at all to have changed contents on paths other than \nalready added to the index when I do so, i.e. an unrelated small\ntypofix in jumping ahead of the real changes I am working on\nin other parts of the tree.\n\n\"Please don't do that\" would break. Jacob says \"avoid the problem\",\nbut I do not see a problem in allowing it (it could be that the\nproblem Jacob has is in other parts of his workflow, but I do not\nknow what it is offhand).\n"},{"id":"304484","messageId":"CA+P7+xq25LcdmtzmBNChiGhGratcdp7m0EOsQuEh68=gJQ9HNQ@mail.gmail.com","threadId":"44332","inReplyTo":"xmqqa8dzhtki.fsf@gitster.mtv.corp.google.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-20T17:27:58Z","receivedAt":"2016-10-20T17:28:25Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>>> I still think it's worth while to add a check for git-commit which\n>>> does something like check when we say \"git commit \" and if the\n>>> index already has those files marked as being changed, compare them\n>>> with the current contents of the file as in the checkout and quick\n>>> saying \"please don't do that\" so as to avoid the problem in the first\n>>> place.\n>> ...\n>> I suspect both of those would complain about legitimate workflows.\n>>\n>> I dunno. I do not ever use \"git commit \" myself.\n>\n> Users are different. I do use this all the time, and it is not\n> unusual at all to have changed contents on paths other than \n> already added to the index when I do so, i.e. an unrelated small\n> typofix in jumping ahead of the real changes I am working on\n> in other parts of the tree.\n>\n> \"Please don't do that\" would break. Jacob says \"avoid the problem\",\n> but I do not see a problem in allowing it (it could be that the\n> problem Jacob has is in other parts of his workflow, but I do not\n> know what it is offhand).\n\nI still think we're misunderstanding. I want git commit to complain\n*only* under the following circumstance:\n\nI run \"git add -p\" and put a partial change into the index in .\nThere are still other parts which were not added to the index yet.\nThus, the index version of the file and the actual file differ.\n\nThen, I (accidentally) run \"git commit \"\n\nI want git commit to complain here that the index and acutal\n being requested are different and it thinks there's an issue.\n\nI do *NOT* want it to complain if I do \"git add -p\" and put parts of\n into the index, and then run\n\ngit commit \n\nDoes that make sense?\n\nBasically if the index and \"git commit \" both say \"add \"\nbut they conflict in what version of I want it to go \"hey..\nuhhh.. that's a bad idea\"\n\nThanks,\nJake\n"},{"id":"304485","messageId":"xmqqwph2hqdg.fsf@gitster.mtv.corp.google.com","threadId":"44332","inReplyTo":"CA+P7+xq25LcdmtzmBNChiGhGratcdp7m0EOsQuEh68=gJQ9HNQ@mail.gmail.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-20T17:39:07Z","receivedAt":"2016-10-20T17:39:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n> I still think we're misunderstanding. I want git commit to complain\n> *only* under the following circumstance:\n>\n> I run \"git add -p\" and put a partial change into the index in .\n> There are still other parts which were not added to the index yet.\n> Thus, the index version of the file and the actual file differ.\n>\n> Then, I (accidentally) run \"git commit \"\n\nI agree that this case is different.\n\nAgain, users are different, and I also often do\n\n $ edit file; think; decide it is a good enough first cut\n $ git add file\n $ edit file; think; decide it is getting better\n $ git add file\n $ edit file; think; decide it is now perfect\n $ git commit file\n\nBecause I do not think you can differentiate the above workflow from\nthe case where \"git add -p\" was used earlier, I think your updated\n\"git commit\" needs to complain at this point.\n\nI am not sure if that is OK. I think it is less not-OK than the use\ncase I mentioned in my earlier message, in that this is not a case\nthat \"please don't do it\" breaks. It however is an inconvenience\nthat the user has to say \"git add file\" before the \"git commit\" (or\n\"git commit file\") to conclude the sequence.\n\nSo I dunno.\n"},{"id":"304494","messageId":"CA+P7+xqbqfCTOHJZJ9ZGXv3oeSvKUdJByc8mdzoAoXRd7UZ6HA@mail.gmail.com","threadId":"44332","inReplyTo":"xmqqwph2hqdg.fsf@gitster.mtv.corp.google.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-20T18:13:57Z","receivedAt":"2016-10-20T18:14:23Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano wrote:\n> Jacob Keller writes:\n>\n>> I still think we're misunderstanding. I want git commit to complain\n>> *only* under the following circumstance:\n>>\n>> I run \"git add -p\" and put a partial change into the index in .\n>> There are still other parts which were not added to the index yet.\n>> Thus, the index version of the file and the actual file differ.\n>>\n>> Then, I (accidentally) run \"git commit \"\n>\n> I agree that this case is different.\n>\n> Again, users are different, and I also often do\n>\n> $ edit file; think; decide it is a good enough first cut\n> $ git add file\n> $ edit file; think; decide it is getting better\n> $ git add file\n> $ edit file; think; decide it is now perfect\n> $ git commit file\n>\n> Because I do not think you can differentiate the above workflow from\n> the case where \"git add -p\" was used earlier, I think your updated\n> \"git commit\" needs to complain at this point.\n>\n> I am not sure if that is OK. I think it is less not-OK than the use\n> case I mentioned in my earlier message, in that this is not a case\n> that \"please don't do it\" breaks. It however is an inconvenience\n> that the user has to say \"git add file\" before the \"git commit\" (or\n> \"git commit file\") to conclude the sequence.\n>\n> So I dunno.\n\nHmmm.. Ya ok I don't think we can actually distinguish between these\ntwo work flows.\n\nGiven that I now know how to fix my mistake easily (git reset -p) I\nthink I will just go ahead and not bother with this as it's much less\nof a pain now.\n\nThanks,\nJake\n"},{"id":"304496","messageId":"xmqqfunqhnhf.fsf@gitster.mtv.corp.google.com","threadId":"44332","inReplyTo":"CA+P7+xqbqfCTOHJZJ9ZGXv3oeSvKUdJByc8mdzoAoXRd7UZ6HA@mail.gmail.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-20T18:41:32Z","receivedAt":"2016-10-20T18:41:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n>> I am not sure if that is OK. I think it is less not-OK than the use\n>> case I mentioned in my earlier message, in that this is not a case\n>> that \"please don't do it\" breaks. It however is an inconvenience\n>> that the user has to say \"git add file\" before the \"git commit\" (or\n>> \"git commit file\") to conclude the sequence.\n>>\n>> So I dunno.\n>\n> Hmmm.. Ya ok I don't think we can actually distinguish between these\n> two work flows.\n\nWhat we might want to have in \"git commit \" is a new mode\nthat is totally different from -i/-o that says roughly \"Start from\nthe tree of HEAD, pretend as if you removed all the paths that match\nthe given pathspec from the tree, and then added all the entries in\nthe index that match that pathspec. Write that tree and commit.\nTake nothing from the working tree\". I have a feeling that when\npeople do\n\n\t$ git add -p file1 file2 file3\n\t$ git commit file2\n\nand ends up including _all_ changes made to file2, not just the ones\nthey picked in the earlier part of the workflow, they are expecting\nsuch a behaviour.\n\n\n\n"},{"id":"304505","messageId":"CA+P7+xoHovFefort6gx6oT4WtT_Toey_0wmmaavLsM=Y1rjx8w@mail.gmail.com","threadId":"44332","inReplyTo":"xmqqfunqhnhf.fsf@gitster.mtv.corp.google.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-20T20:03:28Z","receivedAt":"2016-10-20T20:03:55Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Oct 20, 2016 at 11:41 AM, Junio C Hamano wrote:\n> Jacob Keller writes:\n>\n>>> I am not sure if that is OK. I think it is less not-OK than the use\n>>> case I mentioned in my earlier message, in that this is not a case\n>>> that \"please don't do it\" breaks. It however is an inconvenience\n>>> that the user has to say \"git add file\" before the \"git commit\" (or\n>>> \"git commit file\") to conclude the sequence.\n>>>\n>>> So I dunno.\n>>\n>> Hmmm.. Ya ok I don't think we can actually distinguish between these\n>> two work flows.\n>\n> What we might want to have in \"git commit \" is a new mode\n> that is totally different from -i/-o that says roughly \"Start from\n> the tree of HEAD, pretend as if you removed all the paths that match\n> the given pathspec from the tree, and then added all the entries in\n> the index that match that pathspec. Write that tree and commit.\n> Take nothing from the working tree\". I have a feeling that when\n> people do\n>\n> $ git add -p file1 file2 file3\n> $ git commit file2\n>\n> and ends up including _all_ changes made to file2, not just the ones\n> they picked in the earlier part of the workflow, they are expecting\n> such a behaviour.\n>\n\nRight now I think people who use it intentionally do expect it to work\nthat way. I just happen to not have wanted to add but did so\nanyways without considering, and thus I ended up including changes\nthat were for the next commit.\n\nAs long as there is a way to change \"git commit\" default from that\nmode then we could make the default work and then let people configure\nit to what makes sense.\n\nI'll take a look at going this route.\n\nThanks,\nJake\n"},{"id":"304675","messageId":"147712794056.12237.1478296296628149440@typhoon.fritz.box","threadId":"44332","inReplyTo":"CA+P7+xq25LcdmtzmBNChiGhGratcdp7m0EOsQuEh68=gJQ9HNQ@mail.gmail.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Lukas Fleischer","fromEmail":"lfleischer@lfos.de","sentAt":"2016-10-22T09:19:00Z","receivedAt":"2016-10-22T09:19:10Z","isPatch":false,"sender":{"key":"lfleischer@lfos.de","avatar":"https://avatars.githubusercontent.com/u/5530842?v=4"},"body":"On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:\n> [...]\n> I still think we're misunderstanding. I want git commit to complain\n> *only* under the following circumstance:\n> \n> I run \"git add -p\" and put a partial change into the index in .\n> There are still other parts which were not added to the index yet.\n> Thus, the index version of the file and the actual file differ.\n> \n> Then, I (accidentally) run \"git commit \"\n> [...]\n\nThis reminded me of something that bothered me for a while. It's not\n100% on-topic but still quite related so I thought I'd bring it up.\n\nWhen working on a feature, I usually try to make atomic changes from the\nbeginning and use `git commit -a` to commit them one after another. This\nworks fine most of the time. Sometimes I notice only after making some\nchanges that it might be better to split the working tree changes into\nseveral commits.\n\nIn that case, I git-add the relevant hunks and then, unfortunately, I\noften run `git commit -a` instead of `git commit` (muscle memory bites\nme), so I need to do all the splitting work again.\n\nIt's not much of an issue but would it be worthwhile to add an optional\nfeature (configurable) that warns you when using --all with staged\nchanges (which are not new files)? Are there others having the same\nissue? Do you think this should be implemented as part of an alias\ninstead?\n\nRegards,\nLukas\n"},{"id":"304722","messageId":"CA+P7+xo4AvYMPdHP+JjmSaKRWucywd3t4ckby+0Az=cAo7JrsQ@mail.gmail.com","threadId":"44332","inReplyTo":"147712794056.12237.1478296296628149440@typhoon.fritz.box","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-23T01:07:16Z","receivedAt":"2016-10-23T01:07:42Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sat, Oct 22, 2016 at 2:19 AM, Lukas Fleischer wrote:\n> On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:\n>> [...]\n>> I still think we're misunderstanding. I want git commit to complain\n>> *only* under the following circumstance:\n>>\n>> I run \"git add -p\" and put a partial change into the index in .\n>> There are still other parts which were not added to the index yet.\n>> Thus, the index version of the file and the actual file differ.\n>>\n>> Then, I (accidentally) run \"git commit \"\n>> [...]\n>\n> This reminded me of something that bothered me for a while. It's not\n> 100% on-topic but still quite related so I thought I'd bring it up.\n>\n> When working on a feature, I usually try to make atomic changes from the\n> beginning and use `git commit -a` to commit them one after another. This\n> works fine most of the time. Sometimes I notice only after making some\n> changes that it might be better to split the working tree changes into\n> several commits.\n>\n> In that case, I git-add the relevant hunks and then, unfortunately, I\n> often run `git commit -a` instead of `git commit` (muscle memory bites\n> me), so I need to do all the splitting work again.\n>\n> It's not much of an issue but would it be worthwhile to add an optional\n> feature (configurable) that warns you when using --all with staged\n> changes (which are not new files)? Are there others having the same\n> issue? Do you think this should be implemented as part of an alias\n> instead?\n>\n> Regards,\n> Lukas\n\nThis is (essentially) what I am asking for above. It's the same\noverall problem of \"muscle memory bites me\" and I want the tool to\nchange to help avoiding because I don't think I can win the fight\nagainst muscle memory every time. Being configurable would ensure that\nonly those that want the behavior opt in.\n\nThanks,\nJake\n"},{"id":"304723","messageId":"CACsJy8Bz-DhE+CkJH+3zsrZJUQfGYDN072MKawJ6dx5begfnMw@mail.gmail.com","threadId":"44332","inReplyTo":"147712794056.12237.1478296296628149440@typhoon.fritz.box","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-10-23T01:23:01Z","receivedAt":"2016-10-23T01:23:38Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer wrote:\n> On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:\n>> [...]\n>> I still think we're misunderstanding. I want git commit to complain\n>> *only* under the following circumstance:\n>>\n>> I run \"git add -p\" and put a partial change into the index in .\n>> There are still other parts which were not added to the index yet.\n>> Thus, the index version of the file and the actual file differ.\n>>\n>> Then, I (accidentally) run \"git commit \"\n>> [...]\n>\n> This reminded me of something that bothered me for a while. It's not\n> 100% on-topic but still quite related so I thought I'd bring it up.\n>\n> When working on a feature, I usually try to make atomic changes from the\n> beginning and use `git commit -a` to commit them one after another. This\n> works fine most of the time. Sometimes I notice only after making some\n> changes that it might be better to split the working tree changes into\n> several commits.\n>\n> In that case, I git-add the relevant hunks and then, unfortunately, I\n> often run `git commit -a` instead of `git commit` (muscle memory bites\n> me), so I need to do all the splitting work again.\n>\n> It's not much of an issue but would it be worthwhile to add an optional\n> feature (configurable) that warns you when using --all with staged\n> changes (which are not new files)? Are there others having the same\n> issue? Do you think this should be implemented as part of an alias\n> instead?\n\nI hit the same problem sometimes, but in my case sometimes I\naccidentally do \"git add\" after \"git add -p\" and a configuration in\n\"git commit -a\" won't help me. I'd prefer we could undo changes in\nindex instead. Something like reflog but for index.\n-- \nDuy\n"},{"id":"304724","messageId":"20161023013846.ct3olfabw2yhzio2@sigill.intra.peff.net","threadId":"44332","inReplyTo":"CACsJy8Bz-DhE+CkJH+3zsrZJUQfGYDN072MKawJ6dx5begfnMw@mail.gmail.com","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-23T01:38:47Z","receivedAt":"2016-10-23T01:38:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:\n\n> I hit the same problem sometimes, but in my case sometimes I\n> accidentally do \"git add\" after \"git add -p\" and a configuration in\n> \"git commit -a\" won't help me. I'd prefer we could undo changes in\n> index instead. Something like reflog but for index.\n\nAn index write always writes the whole file from scratch, so you really\njust need to save a copy of the old file. Perhaps something like:\n\n rm -f $GIT_DIR/index.old\n ln $GIT_DIR/index.old $GIT_DIR/index\n ... and then open $GIT_DIR/index.tmp ...\n ... and then rename(index.tmp, index) ...\n\ncould do it cheaply. It's a little more complicated if you want to save\na sequence of versions, and eventually would take a lot of space, but\npresumably a handful of saved indexes would be sufficient.\n\nAnother option would be an index format that journals, and you could\npotentially walk back the journal to a point. That seems like a much\nbigger change (and has weird layering, because deciding when to fold in\nthe journal is usually a performance thing, but obviously this would\nhave user-visible impact about how far back you could undo).\n\n-Peff\n"},{"id":"304756","messageId":"CACsJy8A2Q=cPhYtTexA+CS4mzyx-vHzNH033JFHDih=ohtucVw@mail.gmail.com","threadId":"44332","inReplyTo":"20161023013846.ct3olfabw2yhzio2@sigill.intra.peff.net","subject":"Re: tools for easily \"uncommitting\" parts of a patch I just commited?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-10-23T10:27:45Z","receivedAt":"2016-10-23T10:28:23Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Oct 23, 2016 at 8:38 AM, Jeff King wrote:\n> On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:\n>\n>> I hit the same problem sometimes, but in my case sometimes I\n>> accidentally do \"git add\" after \"git add -p\" and a configuration in\n>> \"git commit -a\" won't help me. I'd prefer we could undo changes in\n>> index instead. Something like reflog but for index.\n>\n> An index write always writes the whole file from scratch, so you really\n> just need to save a copy of the old file. Perhaps something like:\n>\n> rm -f $GIT_DIR/index.old\n> ln $GIT_DIR/index.old $GIT_DIR/index\n> ... and then open $GIT_DIR/index.tmp ...\n> ... and then rename(index.tmp, index) ...\n>\n> could do it cheaply. It's a little more complicated if you want to save\n> a sequence of versions, and eventually would take a lot of space, but\n> presumably a handful of saved indexes would be sufficient.\n\nYeah. I had something [1] like that but never sorted out the UI for it :(\n\n> Another option would be an index format that journals, and you could\n> potentially walk back the journal to a point. That seems like a much\n> bigger change (and has weird layering, because deciding when to fold in\n> the journal is usually a performance thing, but obviously this would\n> have user-visible impact about how far back you could undo).\n\nv2 [2] goes in this direction (but not a full blown COW, the journal\ndoes not take part in any core operations of the index)\n\n[1] https://public-inbox.org/git/%3C1375597720-13236-1-git-send-email-pclouds@gmail.com%3E/\n[2] https://public-inbox.org/git/1375966270-10968-1-git-send-email-pclouds@gmail.com/\n-- \nDuy\n"}]}