{"thread":{"id":"32038","subject":"Re: Revert option for git add --patch","startedAt":"2012-11-08T08:57:19Z","lastAt":"2012-11-09T14:09:06Z","messageCount":5,"participants":["Jonathon Mah","Nguyen Thai Ngoc Duy","Jeff King","Bogolisk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"202630","messageId":"EE89F0A1-1C07-4597-B654-035F657AD09F@me.com","threadId":"32038","inReplyTo":null,"subject":"Re: Revert option for git add --patch","fromName":"Jonathon Mah","fromEmail":"jmah@me.com","sentAt":"2012-11-08T08:57:19Z","receivedAt":"2012-11-08T08:57:19Z","isPatch":false,"sender":{"key":"jmah@me.com","avatar":null},"body":"Nathan,\n\nI find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).\n\nThe interactive staging-and-editing tool could be improved, but I'm not sure that tool should be called 'git add -p'. git add doesn't touch the working tree — at least I hope not, because I wouldn't expect it.\n\nBut I eagerly support more discussion. If someone does want to add this feature to \"git add -p\" (or named differently), I'll add a request for another letter (perhaps '!')  to edit the hunk in the working tree.\n\t\n\n\nJonathon Mah\nme@JonathonMah.com\n"},{"id":"202634","messageId":"CACsJy8CXV=TPWPkNnF7rPRvuObRH=m6RY0KXVXkCaum1EovDCQ@mail.gmail.com","threadId":"32038","inReplyTo":"EE89F0A1-1C07-4597-B654-035F657AD09F@me.com","subject":"Re: Revert option for git add --patch","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-11-08T12:00:06Z","receivedAt":"2012-11-08T12:00:06Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah <jmah@me.com> wrote:\n> Nathan,\n>\n> I find myself performing similar actions to you: using git add -p to stage hunks, sometimes editing the staged patch; and keeping mental notes of things I wanted to revert, sometimes changing them in the editor in another window, and sometimes reverting them after the add session with git checkout -p).\n\nI agree. I'd be really nice to have an interactive command about hunk\nmanipulation between HEAD (or some other ref), index and worktree in\nboth directions (except writing to HEAD, of course). This reminds me\nof the \"git put\" discussion a while ago, which also moves code between\ndifferent locations..\n-- \nDuy\n"},{"id":"202644","messageId":"20121108151501.GB15560@sigill.intra.peff.net","threadId":"32038","inReplyTo":"EE89F0A1-1C07-4597-B654-035F657AD09F@me.com","subject":"Re: Revert option for git add --patch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-08T15:15:03Z","receivedAt":"2012-11-08T15:15:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 08, 2012 at 12:57:19AM -0800, Jonathon Mah wrote:\n\n> I find myself performing similar actions to you: using git add -p to\n> stage hunks, sometimes editing the staged patch; and keeping mental\n> notes of things I wanted to revert, sometimes changing them in the\n> editor in another window, and sometimes reverting them after the add\n> session with git checkout -p).\n\nYeah, I often use a similar workflow. A related one is:\n\n  (1) Make lots of unrelated changes in the working tree.\n\n      $ hack hack hack\n\n  (2) Pick out hunks for the first commit.\n\n      $ git add -p\n\n  (3) Put the rest of the changes aside.\n\n      $ git stash -k\n\n  (4) Test (and possibly tweak) the result, then commit.\n\n      $ make test\n      $ git commit -m \"topic 1\"\n\n  (5) Bring back the stashed changes.\n\n      $ git stash pop\n\n  (6) If there are still interesting changes, goto step 2.\n\n  (7) Otherwise, discard with \"git reset --hard\" or \"git checkout -p\".\n\nI.e., iterating on the changes to put them into several different\ncommits (and achieving a clean, testable state before making each\ncommit).\n\nThe downside of these workflows is that you have to say \"no\" to hunks\nmultiple times (one per iteration) instead of just sorting them in a\nsingle pass. This works OK in practice, but it might be nice to have a\ntool that makes a single pass and lets you drop hunks into buckets\n(topic 1 vs topic 2 vs discard), and then apply the buckets in order,\nstopping to test, tweak, and commit after each one.\n\n> The interactive staging-and-editing tool could be improved, but I'm\n> not sure that tool should be called 'git add -p'. git add doesn't\n> touch the working tree — at least I hope not, because I wouldn't\n> expect it.\n\nRight. I think the idea of one-pass tool is a good one, but it should\nnot be called \"git add -p\".\n\n-Peff\n"},{"id":"202665","messageId":"20121108200449.GA3018@sigill.intra.peff.net","threadId":"32038","inReplyTo":"CAPXHQbPrjZ_Ezi3RkHny-fW0=mQCTmX9NVJfgUh7P-Xx9pgBcg@mail.gmail.com","subject":"Re: Revert option for git add --patch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-08T20:04:49Z","receivedAt":"2012-11-08T20:04:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 09, 2012 at 08:42:33AM +1300, Nathan Broadbent wrote:\n\n> It sounds like we want a tool that combines the functionality of 'git add\n> --patch', 'git checkout --patch', and other features, so that we can\n> perform various actions on 'hunks' without switching context. What do you\n> think about naming this command 'git patch'?\n\nI think it would be a slightly confusing name, given that it is not\nrelated to the usual Unix \"patch\" command (git's analog to that is \"git\napply\").\n\nI was thinking something like \"git organize\" because it is about\norganizing muddled changes. Duy mentioned my earlier \"git put\", which is\nbased around the same ideas. This could be thought of as \"git put\n--patch\", I suppose.\n\n> I'm not sure how dropping hunks into 'buckets' would work, but the main\n> idea is to be able to stage, discard or edit hunks in a single pass.\n\nBuckets are really just patches you are building up from hunks. So I\nthink you are dealing with two buckets either way: a to-stage bucket and\na to-discard bucket. Adding more buckets isn't hard; you just turn the\nto-stage bucket into an array of buckets.\n\nThe tricky part is figuring out how to keep the state persistent across\nmultiple invocations. The simplest program flow for the 2-bucket case\nwould be something like:\n\n  for h in hunks\n  do\n          show hunk to user\n          ask user what they want to do\n          if they want to stage\n             append to to-stage patch\n          else if they want to discard\n             append to to-discard patch\n          else\n             ignore the hunk\n  done\n  feed to-stage patch to \"git apply --cached\"\n  feed to-discard patch to \"git apply -R\"\n\nModifying the loop to have more buckets is easy. But the end is probably\nsomething like:\n\n  feed to-discard patch to \"git apply -R\"\n  feed bucket[0] to \"git apply --cached\"\n  save bucket[1..n] somewhere\n  exit\n\nThen the user gets control back, builds, tests, commits, whatever, and\nthen runs \"git organize --continue\" to apply bucket[1], and so on. And\nsince we don't know what the user did in between, we have to be ready\nfor conflicts in applying the buckets.  Hmm, this is sounding a lot like\nhow \"rebase --interactive\" works.\n\nOne way to implement this would be to store each bucket as a commit\nagainst HEAD (i.e., stage it into a temporary index, then run \"git\nwrite-tree\" and \"git commit-tree\"), and then make a \"rebase -i\"\ninstruction sheet like:\n\n  pick $sha1_of_bucket_1_commit\n  edit\n  pick $sha1_of_bucket_2_commit\n  edit\n\nand so forth, except that we would not want our picks to actually commit\n(just pull the changes into the working tree and/or index).\n\nThat's just me thinking off the top of my head. Obviously what you are\nproposing is way simpler, and it is probably sane to start with the\nsimple thing, and then build the more complex thing on top. But it might\nbe worth keeping in mind the complex case when building out the\ninfrastructure for the simple case.\n\n-Peff\n"},{"id":"202697","messageId":"loom.20121109T150732-186@post.gmane.org","threadId":"32038","inReplyTo":"EE89F0A1-1C07-4597-B654-035F657AD09F@me.com","subject":"Re: Revert option for git add --patch","fromName":"Bogolisk","fromEmail":"bogolisk@gmail.com","sentAt":"2012-11-09T14:09:06Z","receivedAt":"2012-11-09T14:09:06Z","isPatch":false,"sender":{"key":"bogolisk@gmail.com","avatar":null},"body":"Jonathon Mah <jmah <at> me.com> writes:\n\n> \n> Nathan,\n> \n> I find myself performing similar actions to you: using git add -p to stage \nhunks, sometimes editing the\n> staged patch; and keeping mental notes of things I wanted to revert, sometimes \nchanging them in the editor\n> in another window, and sometimes reverting them after the add session with git \ncheckout -p).\n\nOther front-ends like Egg and Magit has been providing the ability to move hunks \nback and forth, for a long time.\n"}]}