{"thread":{"id":"20208","subject":"[PATCH] git-add -p: be able to undo a given hunk","startedAt":"2009-07-23T07:41:04Z","lastAt":"2009-08-19T10:11:34Z","messageCount":76,"participants":["Pierre Habouzit","Thomas Rast","Junio C Hamano","Nanako Shiraishi","Matthias Kestenholz","Jeff King","Bert Wesarg","Elijah Newren","Sverre Rabbelier","Nicolas Sebrecht"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"118564","messageId":"20090723074104.GI4750@laphroaig.corp","threadId":"20208","inReplyTo":null,"subject":"[PATCH] git-add -p: be able to undo a given hunk","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2009-07-23T07:41:04Z","receivedAt":"2009-07-23T07:41:04Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"One of my most frequent use case for git-add -p is when I had an intense\ndebug session with quite a lot of debug() traces added. I then want only\nto select the hunks corresponding to the bugfixes and throw away the debug\nones.\n\nWith this new operation, instead of not staging hunks I don't want and\nwill eventually undo, I can just undo them.\n\nSigned-off-by: Pierre Habouzit \n---\n\n I reckon this is a tad late given we're already at -rc2, but that's\n an itch that has scratched me for quite some time already, and I had\n to scratch it today...\n\n the change looks pretty safe to me though.\n\n The only think that looks odd in the patch is the removal of the\n if ($_->{USE}) clause from the TEXT copying loops, but\n coalesce_overlapping_hunks already ensures that only ->{USE}d hunks\n remain. I just have modified it to deal with ->{UNDO}ed hunks the\n same way.\n\n Documentation/git-add.txt | 1 +\n git-add--interactive.perl | 38 ++++++++++++++++++++++++++++++--------\n 2 files changed, 31 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex ab1943c..7b173dc 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -254,6 +254,7 @@ patch::\n \n y - stage this hunk\n n - do not stage this hunk\n+ u - do not stage this hunk and revert it\n q - quit, do not stage this hunk nor any of the remaining ones\n a - stage this and all the remaining hunks in the file\n d - do not stage this hunk nor any of the remaining hunks in the file\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex df9f231..945de9d 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -693,6 +693,7 @@ sub split_hunk {\n \t\t\tADDDEL => 0,\n \t\t\tPOSTCTX => 0,\n \t\t\tUSE => undef,\n+\t\t\tUNDO => undef,\n \t\t};\n \n \t\twhile (++$i < @$text) {\n@@ -835,12 +836,13 @@ sub merge_hunk {\n }\n \n sub coalesce_overlapping_hunks {\n+\tmy $field = shift;\n \tmy (@in) = @_;\n \tmy @out = ();\n \n \tmy ($last_o_ctx, $last_was_dirty);\n \n-\tfor (grep { $_->{USE} } @in) {\n+\tfor (grep { $_->{$field} } @in) {\n \t\tmy $text = $_->{TEXT};\n \t\tmy ($o_ofs) = parse_hunk_header($text->[0]);\n \t\tif (defined $last_o_ctx &&\n@@ -991,6 +993,7 @@ sub help_patch_cmd {\n \tprint colored $help_color, <<\\EOF ;\n y - stage this hunk\n n - do not stage this hunk\n+u - do not stage this hunk and revert it\n q - quit, do not stage this hunk nor any of the remaining ones\n a - stage this and all the remaining hunks in the file\n d - do not stage this hunk nor any of the remaining hunks in the file\n@@ -1140,7 +1143,7 @@ sub patch_update_file {\n \t\t}\n \t\tprint colored $prompt_color, 'Stage ',\n \t\t ($hunk[$ix]{TYPE} eq 'mode' ? 'mode change' : 'this hunk'),\n-\t\t \" [y,n,q,a,d,/$other,?]? \";\n+\t\t \" [y,n,u,q,a,d,/$other,?]? \";\n \t\tmy $line = prompt_single_character;\n \t\tif ($line) {\n \t\t\tif ($line =~ /^y/i) {\n@@ -1149,6 +1152,10 @@ sub patch_update_file {\n \t\t\telsif ($line =~ /^n/i) {\n \t\t\t\t$hunk[$ix]{USE} = 0;\n \t\t\t}\n+\t\t\telsif ($line =~ /^u/) {\n+\t\t\t\t$hunk[$ix]{USE} = 0;\n+\t\t\t\t$hunk[$ix]{UNDO} = 1;\n+\t\t\t}\n \t\t\telsif ($line =~ /^a/i) {\n \t\t\t\twhile ($ix < $num) {\n \t\t\t\t\tif (!defined $hunk[$ix]{USE}) {\n@@ -1301,14 +1308,14 @@ sub patch_update_file {\n \t\t}\n \t}\n \n-\t@hunk = coalesce_overlapping_hunks(@hunk);\n-\n \tmy $n_lofs = 0;\n \tmy @result = ();\n-\tfor (@hunk) {\n-\t\tif ($_->{USE}) {\n-\t\t\tpush @result, @{$_->{TEXT}};\n-\t\t}\n+\tmy @undo = ();\n+\tfor (coalesce_overlapping_hunks(\"USE\", @hunk)) {\n+\t\tpush @result, @{$_->{TEXT}};\n+\t}\n+\tfor (coalesce_overlapping_hunks(\"UNDO\", @hunk)) {\n+\t\tpush @undo, @{$_->{TEXT}};\n \t}\n \n \tif (@result) {\n@@ -1326,6 +1333,21 @@ sub patch_update_file {\n \t\trefresh();\n \t}\n \n+\tif (@undo) {\n+\t\tmy $fh;\n+\n+\t\topen $fh, '| git apply -R';\n+\t\tfor (@{$head->{TEXT}}, @undo) {\n+\t\t\tprint $fh $_;\n+\t\t}\n+\t\tif (!close $fh) {\n+\t\t\tfor (@{$head->{TEXT}}, @undo) {\n+\t\t\t\tprint STDERR $_;\n+\t\t\t}\n+\t\t}\n+\t\trefresh();\n+\t}\n+\n \tprint \"\\n\";\n \treturn $quit;\n }\n-- \n1.6.4.rc1.189.g9f628.dirty\n"},{"id":"118569","messageId":"200907231041.32567.trast@student.ethz.ch","threadId":"20208","inReplyTo":"20090723074104.GI4750@laphroaig.corp","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-23T08:41:31Z","receivedAt":"2009-07-23T08:41:31Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Pierre Habouzit wrote:\n> One of my most frequent use case for git-add -p is when I had an intense\n> debug session with quite a lot of debug() traces added. I then want only\n> to select the hunks corresponding to the bugfixes and throw away the debug\n> ones.\n> \n> With this new operation, instead of not staging hunks I don't want and\n> will eventually undo, I can just undo them.\n\nThis is what 'git checkout --interactive -- $file' or 'git reset\n--interactive --hard' would accomplish, if they existed. I wonder if\nthere would be a way to avoid yet more command letters, and instead\nhave \"modes\" that affect what happens with hunks you said 'y' to. For\nexample:\n\n add -p\t\tapply --cached\n undo -p\t\tapply -R\n unstage -p\t\tapply -R --cached\n [with hunks coming from diff --cached obviously]\n\n(I picked 'undo' and 'unstage' semi-randomly, but it's not, after all,\nan 'add' operation any more and the user doesn't need to know that the\nprogram doing this is in fact git-add--interactive.)\n\n> + u - do not stage this hunk and revert it\n\nyou're overloading terminology a bit too much for my taste. It has\nnothing to do with what git-revert does, and we shouldn't confuse\npeople more about that.\n\n> Documentation/git-add.txt | 1 +\n> git-add--interactive.perl | 38 ++++++++++++++++++++++++++++++--------\n\nTests?\n\n> @@ -693,6 +693,7 @@ sub split_hunk {\n> \t\t\tADDDEL => 0,\n> \t\t\tPOSTCTX => 0,\n> \t\t\tUSE => undef,\n> +\t\t\tUNDO => undef,\n> \t\t};\n\nWhy not fold this into a single field? It could, say, take values 0,\n1, or '-R'. It could probably be renamed to ACTION, but USE would be\nfine if you want to avoid the code churn. Then you shouldn't need\n_completely_ separate handling during application.\n\n> @@ -1149,6 +1152,10 @@ sub patch_update_file {\n> \t\t\telsif ($line =~ /^n/i) {\n> \t\t\t\t$hunk[$ix]{USE} = 0;\n\n+\t\t\t\t$hunk[$ix]{UNDO} = 0;\n\nand similarly for [yad] too, on the grounds that the user can go back\nand change his choices with [KJ]. Of course that is not necessary if\nyou go the ACTION way outlined above.\n\n> +\tif (@undo) {\n> +\t\tmy $fh;\n> +\n> +\t\topen $fh, '| git apply -R';\n\nThis probably needs a --recount to cope with the case where the hunk\nheaders became stale/invalid through user [e]diting.\n\n> +\t\tfor (@{$head->{TEXT}}, @undo) {\n> +\t\t\tprint $fh $_;\n> +\t\t}\n> +\t\tif (!close $fh) {\n> +\t\t\tfor (@{$head->{TEXT}}, @undo) {\n> +\t\t\t\tprint STDERR $_;\n> +\t\t\t}\n> +\t\t}\n> +\t\trefresh();\n> +\t}\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"118570","messageId":"20090723085046.GK4750@laphroaig.corp","threadId":"20208","inReplyTo":"200907231041.32567.trast@student.ethz.ch","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-07-23T08:50:47Z","receivedAt":"2009-07-23T08:50:47Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Thu, Jul 23, 2009 at 10:41:31AM +0200, Thomas Rast wrote:\n> Pierre Habouzit wrote:\n> > One of my most frequent use case for git-add -p is when I had an intense\n> > debug session with quite a lot of debug() traces added. I then want only\n> > to select the hunks corresponding to the bugfixes and throw away the debug\n> > ones.\n> > \n> > With this new operation, instead of not staging hunks I don't want and\n> > will eventually undo, I can just undo them.\n> \n> This is what 'git checkout --interactive -- $file' or 'git reset\n> --interactive --hard' would accomplish, if they existed. I wonder if\n> there would be a way to avoid yet more command letters, and instead\n> have \"modes\" that affect what happens with hunks you said 'y' to. For\n> example:\n> \n> add -p\t\tapply --cached\n> undo -p\t\tapply -R\n> unstage -p\t\tapply -R --cached\n> [with hunks coming from diff --cached obviously]\n> \n> (I picked 'undo' and 'unstage' semi-randomly, but it's not, after all,\n> an 'add' operation any more and the user doesn't need to know that the\n> program doing this is in fact git-add--interactive.)\n\nThe point is I want to do them at once, see my use case: I want to stage\nthe hunks from my bugfix, and remove the debugging bits of it at the\nsame time, I don't want to run two commands.\n\nI see git add -p as a triaging command, giving me the choice to do the\nthree things you can do with a hunk:\n - stage it now (y)\n - stage it later (n)\n - never stage it, it was intermediate code, debug, whatever (u).\n\n> > + u - do not stage this hunk and revert it\n> \n> you're overloading terminology a bit too much for my taste. It has\n> nothing to do with what git-revert does, and we shouldn't confuse\n> people more about that.\n\nRight, revert is probably too overloaded, let it be \"forget\" or \"drop\"\ninstead if you want, I don't care much.\n\n> > Documentation/git-add.txt | 1 +\n> > git-add--interactive.perl | 38 ++++++++++++++++++++++++++++++--------\n> \n> Tests?\n\nRiight, will do :)\n\n> > @@ -693,6 +693,7 @@ sub split_hunk {\n> > \t\t\tADDDEL => 0,\n> > \t\t\tPOSTCTX => 0,\n> > \t\t\tUSE => undef,\n> > +\t\t\tUNDO => undef,\n> > \t\t};\n> \n> Why not fold this into a single field? It could, say, take values 0,\n> 1, or '-R'. It could probably be renamed to ACTION, but USE would be\n> fine if you want to avoid the code churn. Then you shouldn't need\n> _completely_ separate handling during application.\n> \n> > @@ -1149,6 +1152,10 @@ sub patch_update_file {\n> > \t\t\telsif ($line =~ /^n/i) {\n> > \t\t\t\t$hunk[$ix]{USE} = 0;\n> \n> +\t\t\t\t$hunk[$ix]{UNDO} = 0;\n> \n> and similarly for [yad] too, on the grounds that the user can go back\n> and change his choices with [KJ]. Of course that is not necessary if\n> you go the ACTION way outlined above.\n\nI hesitated to do so, but yes it makes perfect sense.\n\n> > +\tif (@undo) {\n> > +\t\tmy $fh;\n> > +\n> > +\t\topen $fh, '| git apply -R';\n> \n> This probably needs a --recount to cope with the case where the hunk\n> headers became stale/invalid through user [e]diting.\n\nIndeed.\n\n-- \nIntersec \nPierre Habouzit \nTél : +33 (0)1 5570 3346\nMob : +33 (0)6 1636 8131\nFax : +33 (0)1 5570 3332\n37 Rue Pierre Lhomme\n92400 Courbevoie\n"},{"id":"118604","messageId":"7veis7yxwx.fsf@alter.siamese.dyndns.org","threadId":"20208","inReplyTo":"20090723074104.GI4750@laphroaig.corp","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-23T19:58:06Z","receivedAt":"2009-07-23T19:58:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> One of my most frequent use case for git-add -p is when I had an intense\n> debug session with quite a lot of debug() traces added. I then want only\n> to select the hunks corresponding to the bugfixes and throw away the debug\n> ones.\n\nI do not particularly like this change. \"add -i\", \"add -p\" and \"add\" in\ngeneral are about manipulating the index. They are never meant to touch\nthe work tree contents. Which means that even if you make a mistake in\nsaying y/n, you won't damange the state you have in your work tree, and\nalso means that you can recover safely by simply restarting \"add -p\"\nsession if you really botched splitting of the patch.\n\nI fear tempting a new user who sees \"undo\" to say \"yeah, I added the\nchange in this hunk to the index by mistake, please undo\", which would\nlose the work. The confusion is easier to avoid if \"add\" only manipulates\nthe index without harming the work tree, and the user used a different\ncommand, namely \"checkout from the index\", to get rid of the remaining\ndebug cruft, once s/he added all the necessary bits to the index perhaps\nafter a multi-stage commit session.\n"},{"id":"118619","messageId":"2d756f643fc7d1b50cf590c95467fa029b49ff46.1248426652.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"200907231041.32567.trast@student.ethz.ch","subject":"[RFC PATCH] Implement unstage and reset modes for git-add--interactive","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-24T09:15:51Z","receivedAt":"2009-07-24T09:15:51Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"This is just the required change to git-add--interactive. Since the\nuse of this script is an implementation detail, the next step would be\nto wrap this option in other commands such as 'git reset --patch' and\n'git unstage --patch'.\n\nSince there is no frontend support whatsoever, you have to run\n\n git add--interactive --patch=unstage --\n\nmanually (including the --), and similarly for --patch=reset.\n---\n\nI wrote:\n> This is what 'git checkout --interactive -- $file' or 'git reset\n> --interactive --hard' would accomplish, if they existed. I wonder if\n> there would be a way to avoid yet more command letters, and instead\n> have \"modes\" that affect what happens with hunks you said 'y' to. For\n> example:\n> \n> add -p apply --cached\n> undo -p apply -R\n> unstage -p apply -R --cached\n> [with hunks coming from diff --cached obviously]\n> \n> (I picked 'undo' and 'unstage' semi-randomly, but it's not, after all,\n> an 'add' operation any more and the user doesn't need to know that the\n> program doing this is in fact git-add--interactive.)\n\nLike so, maybe. I realise that it does _not_ fill Pierre's need for a\ncommand that can do it all in one go, but if people like this I'll\nmake a real patch series.\n\nI'm not completely happy with the idea of reset --interactive by the\nway, as it's not a reset in the 'reset $commit' sense.\n\n\n\n git-add--interactive.perl | 60 +++++++++++++++++++++++++++++++++-----------\n 1 files changed, 45 insertions(+), 15 deletions(-)\n\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex df9f231..ad322df 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -73,6 +73,27 @@\n # command line options\n my $patch_mode;\n \n+my %patch_modes = (\n+\t'stage' => {\n+\t\tDIFF => 'diff-files -p',\n+\t\tAPPLY => 'apply --cached',\n+\t\tVERB => 'Stage',\n+\t\tPARTICIPLE => 'Staging',\n+\t},\n+\t'unstage' => {\n+\t\tDIFF => 'diff-index -p --cached HEAD',\n+\t\tAPPLY => 'apply -R --cached',\n+\t\tVERB => 'UNstage',\n+\t\tPARTICIPLE => 'UNstaging',\n+\t},\n+\t'reset' => {\n+\t\tDIFF => 'diff-files -p',\n+\t\tAPPLY => 'apply -R',\n+\t\tVERB => 'RESET',\n+\t\tPARTICIPLE => 'RESETTING',\n+\t},\n+);\n+\n sub run_cmd_pipe {\n \tif ($^O eq 'MSWin32' || $^O eq 'msys') {\n \t\tmy @invalid = grep {m/[\":*]/} @_;\n@@ -615,10 +636,11 @@\n \n sub parse_diff {\n \tmy ($path) = @_;\n-\tmy @diff = run_cmd_pipe(qw(git diff-files -p --), $path);\n+\tmy @diff_cmd = split(\" \", $patch_modes{$patch_mode}{DIFF});\n+\tmy @diff = run_cmd_pipe(\"git\", @diff_cmd, \"--\", $path);\n \tmy @colored = ();\n \tif ($diff_use_color) {\n-\t\t@colored = run_cmd_pipe(qw(git diff-files -p --color --), $path);\n+\t\t@colored = run_cmd_pipe(\"git\", @diff_cmd, qw(--color --), $path);\n \t}\n \tmy (@hunk) = { TEXT => [], DISPLAY => [], TYPE => 'header' };\n \n@@ -877,6 +899,7 @@\n \t\tor die \"failed to open hunk edit file for writing: \" . $!;\n \tprint $fh \"# Manual hunk edit mode -- see bottom for a quick guide\\n\";\n \tprint $fh @$oldtext;\n+\tmy $participle = $patch_modes{$patch_mode}{PARTICIPLE};\n \tprint $fh <{TEXT}};\n \t}\n@@ -988,12 +1011,13 @@\n }\n \n sub help_patch_cmd {\n-\tprint colored $help_color, <<\\EOF ;\n-y - stage this hunk\n-n - do not stage this hunk\n-q - quit, do not stage this hunk nor any of the remaining ones\n-a - stage this and all the remaining hunks in the file\n-d - do not stage this hunk nor any of the remaining hunks in the file\n+\tmy $verb = lc $patch_modes{$patch_mode}{VERB};\n+\tprint colored $help_color, <{TEXT}}, @result) {\n \t\t\tprint $fh $_;\n \t\t}\n@@ -1363,8 +1387,14 @@\n sub process_args {\n \treturn unless @ARGV;\n \tmy $arg = shift @ARGV;\n-\tif ($arg eq \"--patch\") {\n-\t\t$patch_mode = 1;\n+\tif ($arg =~ /--patch(?:=(.*))?/) {\n+\t\tif (defined $1 && defined $patch_modes{$1}) {\n+\t\t\t$patch_mode = $1;\n+\t\t} elsif (defined $1) {\n+\t\t\tdie \"unknown --patch mode: $1\";\n+\t\t} else {\n+\t\t\t$patch_mode = 'stage';\n+\t\t}\n \t\t$arg = shift @ARGV or die \"missing --\";\n \t\tdie \"invalid argument $arg, expecting --\"\n \t\t unless $arg eq \"--\";\n-- \n1.6.4.rc2.215.g4f661\n"},{"id":"118625","messageId":"20090724193207.6117@nanako3.lavabit.com","threadId":"20208","inReplyTo":"7veis7yxwx.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-07-24T10:32:07Z","receivedAt":"2009-07-24T10:32:07Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano \n\n> I fear tempting a new user who sees \"undo\" to say \"yeah, I added the\n> change in this hunk to the index by mistake, please undo\", which would\n> lose the work. The confusion is easier to avoid if \"add\" only manipulates\n> the index without harming the work tree, and the user used a different\n> command, namely \"checkout from the index\", to get rid of the remaining\n> debug cruft, once s/he added all the necessary bits to the index perhaps\n> after a multi-stage commit session.\n\nI can see your argument that this might introduce more danger for newbies. As you said yourself number of times, nobody will stay being a newbie forever, and I don't think it is wise to reject a feature that is very handy for experts based solely on such a fear.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"118628","messageId":"20090724145851.GH4903@laphroaig.corp","threadId":"20208","inReplyTo":"7veis7yxwx.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-07-24T14:58:51Z","receivedAt":"2009-07-24T14:58:51Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Thu, Jul 23, 2009 at 12:58:06PM -0700, Junio C Hamano wrote:\n> Pierre Habouzit writes:\n> \n> > One of my most frequent use case for git-add -p is when I had an intense\n> > debug session with quite a lot of debug() traces added. I then want only\n> > to select the hunks corresponding to the bugfixes and throw away the debug\n> > ones.\n> \n> I do not particularly like this change. \"add -i\", \"add -p\" and \"add\" in\n> general are about manipulating the index. They are never meant to touch\n> the work tree contents. Which means that even if you make a mistake in\n> saying y/n, you won't damange the state you have in your work tree, and\n> also means that you can recover safely by simply restarting \"add -p\"\n> session if you really botched splitting of the patch.\n\nOkay, fair enough, this is kind of mixing stuff together, I reckon. OTOH\nthis fills out a real need: sorting out the debug code from the non\ndebug one, it's particularily handy, and many people at work here have\napplied my patch and it saves them lots of time.\n\nSo maybe we should see how to have a new command like git hunk-sort or\ngit hunk-triage or whatever, I don't really mind.\n\nAnother way, that is non destructive is to _not_ apply the reverting\npatch, but only to generate it, and let the user apply it himself. E.g.\nsomething along the lines of:\n\n$ git add -p\n... select your patches ...\ninfo: you have selected hunks for removal from you tree\ninfo: run the following command to make them go away:\n git apply -R --recount git-add-undo-12asWED.patch\n$\n\nAnd let the user cut & paste the command.\n\n_I_ could live with that, and you lose the dangerous factor.\n\n-- \nIntersec \nPierre Habouzit \nTél : +33 (0)1 5570 3346\nMob : +33 (0)6 1636 8131\nFax : +33 (0)1 5570 3332\n37 Rue Pierre Lhomme\n92400 Courbevoie\n"},{"id":"118634","messageId":"7v8wienk07.fsf@alter.siamese.dyndns.org","threadId":"20208","inReplyTo":"20090724193207.6117@nanako3.lavabit.com","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-24T16:06:16Z","receivedAt":"2009-07-24T16:06:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Junio C Hamano \n>\n>> I fear tempting a new user who sees \"undo\" to say \"yeah, I added the\n>> change in this hunk to the index by mistake, please undo\", which would\n>> lose the work. The confusion is easier to avoid if \"add\" only manipulates\n>> the index without harming the work tree, and the user used a different\n>> command, namely \"checkout from the index\", to get rid of the remaining\n>> debug cruft, once s/he added all the necessary bits to the index perhaps\n>> after a multi-stage commit session.\n>\n> I can see your argument that this might introduce more danger for\n> newbies. As you said yourself number of times, nobody will stay being a\n> newbie forever, and I don't think it is wise to reject a feature that is\n> very handy for experts based solely on such a fear.\n\nIt is true that as new people learn they gain proficiency, and you are\nalso right to point out that I'd usually choose to optimize the interface\nfor making the life of experts easier rather than welding training wheels\nto the system.\n\nBUT\n\nAs new people gain proficiency in git, three things happen.\n\n (1) It becomes a lot less likely for them to make mistakes in choosing\n commands. I mentioned that they may misunderstand what Pierre's\n \"undo\" would do, and that fear may be alleviated because of this.\n\n (2) It does _not_ become less likely for them to make typos when giving\n the command they chose. The chance of saying 'u' when you mean 'y'\n does not decrease that much as you become more used to using git.\n Especially with interactive.singlekey, the consequence of such a typo\n is devastating.\n\n (3) They form a better mental model of how the world works.\n\n The high level view of the git workflow is for you to:\n\n (a) prepare good changes, together with some changes that are not\n quite ready, in your work tree; and\n\n (b) use \"git add\" to add only good changes suitable for the next\n commit to the index; and finally\n\n (c) make the next commit out of the index. Repeat (b) and (c) as\n necessary to create multiple commits.\n\n If you botch the \"git add\" step during this process, because \"git\n add\" promises not to touch the work tree, you can safely reset the\n index entry to its previous state and redo the \"git add\" step,\n without having to fear that you may lose your work.\n\nIn your arsenal, you have \"git add -p\" to help you sift good pieces from\nother parts in finer grained manner, instead of having to make an all or\nnothing decision per file basis (i.e. \"git add file\"). But \"git add -p\"\n(and \"git add -i\") is still about the \"git add\" step in the above high\nlevel view. You have a mixture of good and not so good changes in your\nwork tree, and you pick only good pieces to add to the index, _knowing_\nthat you can go back and redo this step safely exactly because your work\ntree will stay the same even if you did make mistakes.\n\nThe proposed change breaks this expectation you would have naturally\ngained during the course of becoming more and more proficient in using\ngit.\n\nIn other words, I do not think you can say that the change will not harm\nthe experts due to both the points 2 (experts can easily make typo) and 3\nabove (the change breaks the mental model of the world experts would have\nformed).\n\nHaving said all that, it indeed would be useful to selectively revert\nchanges from the work tree files.\n\nEven though you could add good bits interactively, making multiple\ncommits, and remove the remaining debugging cruft at the very end with\n\"git checkout $files\" or \"git reset --hard\", if there are debugging crufts\nfor two or more phases of development, this alternative procedure would\nnot work well, compared to the workflow using Pierre's 'u', which allows\nyou to add necessary bits to commit one phase, remove the debugging bits\nfor that phase (but keeping other debugging bits for the remaining good\nparts), then continue working and repeat committing and cleaning second\nand subsequent phases.\n\nIt might be enough to change the command key to uppercase \"U\" to avoid\nunintended mistakes, and document the fact prominently that this action is\nan oddball exception to the principle of \"git add\", while describing why\nit is an oddball, along the lines of the above discussion, if necessary.\n"},{"id":"118635","messageId":"683ed99f389d643d21bda6750bd2ee9caf287625.1248452530.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"2d756f643fc7d1b50cf590c95467fa029b49ff46.1248426652.git.trast@student.ethz.ch","subject":"[RFC PATCH v2 1/3] Introduce git-unstage","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-24T16:24:34Z","receivedAt":"2009-07-24T16:24:34Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"The new command 'git unstage' is the precise opposite of 'git stage'\n(i.e., git-add). As such, it is the same as 'git reset --' unless the\ncurrent branch is unborn.\n\nSigned-off-by: Thomas Rast \n---\n\nSo I decided I had wished for these frequently enough to actually\nimplement them. I ran out of time before getting to the tests, but\nthe rest should be there.\n\nv1 had a bug where it would not correctly detect the changed files,\nthis is fixed in the new patch (now 3/3).\n\n\n Documentation/git-unstage.txt | 26 ++++++++++++++++++++++++++\n Makefile | 1 +\n git-unstage.sh | 26 ++++++++++++++++++++++++++\n wt-status.c | 6 +-----\n 4 files changed, 54 insertions(+), 5 deletions(-)\n create mode 100644 Documentation/git-unstage.txt\n create mode 100644 git-unstage.sh\n\ndiff --git a/Documentation/git-unstage.txt b/Documentation/git-unstage.txt\nnew file mode 100644\nindex 0000000..49d09fb\n--- /dev/null\n+++ b/Documentation/git-unstage.txt\n@@ -0,0 +1,26 @@\n+git-unstage(1)\n+==============\n+\n+NAME\n+----\n+git-unstage - Remove changes to a file from the staging area\n+\n+\n+SYNOPSIS\n+--------\n+[verse]\n+'git unstage' ...\n+\n+\n+DESCRIPTION\n+-----------\n+\n+Overwrites the staged changes to the 'paths' with the values from\n+HEAD, so that they are not included in the next commit. The worktree\n+is not affected. (This is the same as `git reset \\-- ` unless\n+you are on an unborn branch.)\n+\n+\n+SEE ALSO\n+--------\n+linkgit:git-reset[1]\ndiff --git a/Makefile b/Makefile\nindex 75b9dcb..9e48fdc 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -329,6 +329,7 @@ SCRIPT_SH += git-request-pull.sh\n SCRIPT_SH += git-sh-setup.sh\n SCRIPT_SH += git-stash.sh\n SCRIPT_SH += git-submodule.sh\n+SCRIPT_SH += git-unstage.sh\n SCRIPT_SH += git-web--browse.sh\n \n SCRIPT_PERL += git-add--interactive.perl\ndiff --git a/git-unstage.sh b/git-unstage.sh\nnew file mode 100644\nindex 0000000..7f99adf\n--- /dev/null\n+++ b/git-unstage.sh\n@@ -0,0 +1,26 @@\n+#!/bin/sh\n+\n+SUBDIRECTORY_OK=Yes\n+OPTIONS_KEEPDASHDASH=\n+OPTIONS_SPEC=\"\\\n+git unstage file ...\n+--\"\n+\n+. git-sh-setup\n+\n+\n+case \"$1\" in\n+ --)\n+\tif [ $# -eq 1 ]; then\n+\t die \"You must specify at least one file to unstage\"\n+\tfi\n+\tif git rev-parse -q --verify HEAD >/dev/null; then\n+\t exec git reset \"$@\"\n+\telse\n+\t exec git rm --cached \"$@\"\n+\tfi\n+\t;;\n+ *)\n+\tusage\n+\t;;\n+esac\ndiff --git a/wt-status.c b/wt-status.c\nindex 47735d8..f1a74a4 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -62,11 +62,7 @@ static void wt_status_print_cached_header(struct wt_status *s)\n {\n \tconst char *c = color(WT_STATUS_HEADER);\n \tcolor_fprintf_ln(s->fp, c, \"# Changes to be committed:\");\n-\tif (!s->is_initial) {\n-\t\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git reset %s ...\\\" to unstage)\", s->reference);\n-\t} else {\n-\t\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git rm --cached ...\\\" to unstage)\");\n-\t}\n+\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git unstage %s ...\\\" to unstage)\", s->reference);\n \tcolor_fprintf_ln(s->fp, c, \"#\");\n }\n \n-- \n1.6.4.rc2.217.g74c0b.dirty\n"},{"id":"118636","messageId":"cf51e6aa92ea98fc9409826cc0468a01fdf7b01e.1248452530.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"2d756f643fc7d1b50cf590c95467fa029b49ff46.1248426652.git.trast@student.ethz.ch","subject":"[RFC PATCH v2 2/3] Introduce git-discard","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-24T16:24:35Z","receivedAt":"2009-07-24T16:24:35Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"The new command 'git discard' is precisely the same as 'git checkout --'.\n\nSigned-off-by: Thomas Rast \n---\n Documentation/git-discard.txt | 29 +++++++++++++++++++++++++++++\n Makefile | 1 +\n git-discard.sh | 22 ++++++++++++++++++++++\n wt-status.c | 2 +-\n 4 files changed, 53 insertions(+), 1 deletions(-)\n create mode 100644 Documentation/git-discard.txt\n create mode 100644 git-discard.sh\n\ndiff --git a/Documentation/git-discard.txt b/Documentation/git-discard.txt\nnew file mode 100644\nindex 0000000..4db14f0\n--- /dev/null\n+++ b/Documentation/git-discard.txt\n@@ -0,0 +1,29 @@\n+git-discard(1)\n+==============\n+\n+NAME\n+----\n+git-discard - Remove changes to a file from the worktree\n+\n+\n+SYNOPSIS\n+--------\n+[verse]\n+'git discard' ...\n+\n+\n+DESCRIPTION\n+-----------\n+\n+Overwrites your edits to the 'paths' with the values from the staging\n+area, effectively throwing them away entirely.\n+\n+*WARNING:* All unstaged changes to the 'paths' are *irreversibly*\n+lost.\n+\n+(This is the same as `git checkout \\-- `.)\n+\n+\n+SEE ALSO\n+--------\n+linkgit:git-checkout[1]\ndiff --git a/Makefile b/Makefile\nindex 9e48fdc..814d4b6 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -312,6 +312,7 @@ TEST_PROGRAMS =\n SCRIPT_SH += git-am.sh\n SCRIPT_SH += git-bisect.sh\n SCRIPT_SH += git-difftool--helper.sh\n+SCRIPT_SH += git-discard.sh\n SCRIPT_SH += git-filter-branch.sh\n SCRIPT_SH += git-lost-found.sh\n SCRIPT_SH += git-merge-octopus.sh\ndiff --git a/git-discard.sh b/git-discard.sh\nnew file mode 100644\nindex 0000000..595df98\n--- /dev/null\n+++ b/git-discard.sh\n@@ -0,0 +1,22 @@\n+#!/bin/sh\n+\n+SUBDIRECTORY_OK=Yes\n+OPTIONS_KEEPDASHDASH=\n+OPTIONS_SPEC=\"\\\n+git discard file ...\n+--\"\n+\n+. git-sh-setup\n+\n+\n+case \"$1\" in\n+ --)\n+\tif [ $# -eq 1 ]; then\n+\t die \"You must specify at least one file to discard changes from\"\n+\tfi\n+\texec git checkout \"$@\"\n+\t;;\n+ *)\n+\tusage\n+\t;;\n+esac\ndiff --git a/wt-status.c b/wt-status.c\nindex f1a74a4..1dd4bed 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -75,7 +75,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,\n \t\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git add ...\\\" to update what will be committed)\");\n \telse\n \t\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git add/rm ...\\\" to update what will be committed)\");\n-\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git checkout -- ...\\\" to discard changes in working directory)\");\n+\tcolor_fprintf_ln(s->fp, c, \"# (use \\\"git discard ...\\\" to discard changes in working directory)\");\n \tcolor_fprintf_ln(s->fp, c, \"#\");\n }\n \n-- \n1.6.4.rc2.217.g74c0b.dirty\n"},{"id":"118637","messageId":"9cad6176fe941bd56bad7fed49cc55a96a7040ae.1248452530.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"2d756f643fc7d1b50cf590c95467fa029b49ff46.1248426652.git.trast@student.ethz.ch","subject":"[RFC PATCH v2 3/3] Implement unstage --patch and discard --patch","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-24T16:24:36Z","receivedAt":"2009-07-24T16:24:36Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"This implements a new optional argument --patch= in the\ngit-add--interactive helper. The modes are:\n\n'stage' (default, as before): offer hunks from 'git diff' and stage\n the ones selected by the user.\n\n'unstage': offer hunks from 'git diff --cached', and unstage the ones\n selected.\n\n'discard': offer hunks from 'git diff', and discard (i.e., undo the\n edit in the working tree) the ones selected.\n\nWith this in hand, we can then easily add a --patch option to the\ngit-unstage and git-discard scripts that run git-add--interactive in\nthe corresponding modes.\n\nSigned-off-by: Thomas Rast \n---\n Documentation/git-discard.txt | 7 ++++\n Documentation/git-unstage.txt | 7 ++++\n git-add--interactive.perl | 69 +++++++++++++++++++++++++++++++---------\n git-discard.sh | 9 ++++-\n git-unstage.sh | 9 ++++-\n 5 files changed, 81 insertions(+), 20 deletions(-)\n\ndiff --git a/Documentation/git-discard.txt b/Documentation/git-discard.txt\nindex 4db14f0..2c063d1 100644\n--- a/Documentation/git-discard.txt\n+++ b/Documentation/git-discard.txt\n@@ -24,6 +24,13 @@ lost.\n (This is the same as `git checkout \\-- `.)\n \n \n+OPTIONS\n+-------\n+-p::\n+--patch::\n+\tInteractively select hunks to discard.\n+\n+\n SEE ALSO\n --------\n linkgit:git-checkout[1]\ndiff --git a/Documentation/git-unstage.txt b/Documentation/git-unstage.txt\nindex 49d09fb..d3da3e1 100644\n--- a/Documentation/git-unstage.txt\n+++ b/Documentation/git-unstage.txt\n@@ -21,6 +21,13 @@ is not affected. (This is the same as `git reset \\-- ` unless\n you are on an unborn branch.)\n \n \n+OPTIONS\n+-------\n+-p::\n+--patch::\n+\tInteractively select hunks to unstage.\n+\n+\n SEE ALSO\n --------\n linkgit:git-reset[1]\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex df9f231..502a0e4 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -73,6 +73,30 @@\n # command line options\n my $patch_mode;\n \n+my %patch_modes = (\n+\t'stage' => {\n+\t\tDIFF => 'diff-files -p',\n+\t\tAPPLY => 'apply --cached',\n+\t\tVERB => 'Stage',\n+\t\tPARTICIPLE => 'Staging',\n+\t\tFILTER => 'file-only',\n+\t},\n+\t'unstage' => {\n+\t\tDIFF => 'diff-index -p --cached HEAD',\n+\t\tAPPLY => 'apply -R --cached',\n+\t\tVERB => 'UNstage',\n+\t\tPARTICIPLE => 'UNstaging',\n+\t\tFILTER => 'index-only',\n+\t},\n+\t'discard' => {\n+\t\tDIFF => 'diff-files -p',\n+\t\tAPPLY => 'apply -R',\n+\t\tVERB => 'RESET',\n+\t\tPARTICIPLE => 'RESETTING',\n+\t\tFILTER => 'file-only',\n+\t},\n+);\n+\n sub run_cmd_pipe {\n \tif ($^O eq 'MSWin32' || $^O eq 'msys') {\n \t\tmy @invalid = grep {m/[\":*]/} @_;\n@@ -615,10 +639,11 @@\n \n sub parse_diff {\n \tmy ($path) = @_;\n-\tmy @diff = run_cmd_pipe(qw(git diff-files -p --), $path);\n+\tmy @diff_cmd = split(\" \", $patch_modes{$patch_mode}{DIFF});\n+\tmy @diff = run_cmd_pipe(\"git\", @diff_cmd, \"--\", $path);\n \tmy @colored = ();\n \tif ($diff_use_color) {\n-\t\t@colored = run_cmd_pipe(qw(git diff-files -p --color --), $path);\n+\t\t@colored = run_cmd_pipe(\"git\", @diff_cmd, qw(--color --), $path);\n \t}\n \tmy (@hunk) = { TEXT => [], DISPLAY => [], TYPE => 'header' };\n \n@@ -877,6 +902,7 @@\n \t\tor die \"failed to open hunk edit file for writing: \" . $!;\n \tprint $fh \"# Manual hunk edit mode -- see bottom for a quick guide\\n\";\n \tprint $fh @$oldtext;\n+\tmy $participle = $patch_modes{$patch_mode}{PARTICIPLE};\n \tprint $fh <{TEXT}};\n \t}\n@@ -988,12 +1014,13 @@\n }\n \n sub help_patch_cmd {\n-\tprint colored $help_color, <<\\EOF ;\n-y - stage this hunk\n-n - do not stage this hunk\n-q - quit, do not stage this hunk nor any of the remaining ones\n-a - stage this and all the remaining hunks in the file\n-d - do not stage this hunk nor any of the remaining hunks in the file\n+\tmy $verb = lc $patch_modes{$patch_mode}{VERB};\n+\tprint colored $help_color, <{BINARY}) } @all_mods;\n \tmy @them;\n \n@@ -1138,8 +1169,8 @@\n \t\tfor (@{$hunk[$ix]{DISPLAY}}) {\n \t\t\tprint;\n \t\t}\n-\t\tprint colored $prompt_color, 'Stage ',\n-\t\t ($hunk[$ix]{TYPE} eq 'mode' ? 'mode change' : 'this hunk'),\n+\t\tprint colored $prompt_color, $patch_modes{$patch_mode}{VERB},\n+\t\t ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' : ' this hunk'),\n \t\t \" [y,n,q,a,d,/$other,?]? \";\n \t\tmy $line = prompt_single_character;\n \t\tif ($line) {\n@@ -1314,7 +1345,7 @@\n \tif (@result) {\n \t\tmy $fh;\n \n-\t\topen $fh, '| git apply --cached --recount';\n+\t\topen $fh, '| git '.$patch_modes{$patch_mode}{APPLY}.' --recount';\n \t\tfor (@{$head->{TEXT}}, @result) {\n \t\t\tprint $fh $_;\n \t\t}\n@@ -1363,8 +1394,14 @@\n sub process_args {\n \treturn unless @ARGV;\n \tmy $arg = shift @ARGV;\n-\tif ($arg eq \"--patch\") {\n-\t\t$patch_mode = 1;\n+\tif ($arg =~ /--patch(?:=(.*))?/) {\n+\t\tif (defined $1 && defined $patch_modes{$1}) {\n+\t\t\t$patch_mode = $1;\n+\t\t} elsif (defined $1) {\n+\t\t\tdie \"unknown --patch mode: $1\";\n+\t\t} else {\n+\t\t\t$patch_mode = 'stage';\n+\t\t}\n \t\t$arg = shift @ARGV or die \"missing --\";\n \t\tdie \"invalid argument $arg, expecting --\"\n \t\t unless $arg eq \"--\";\ndiff --git a/git-discard.sh b/git-discard.sh\nindex 595df98..628346d 100644\n--- a/git-discard.sh\n+++ b/git-discard.sh\n@@ -3,13 +3,18 @@\n SUBDIRECTORY_OK=Yes\n OPTIONS_KEEPDASHDASH=\n OPTIONS_SPEC=\"\\\n-git discard file ...\n---\"\n+git discard [-p] file ...\n+--\n+p,patch interactively select hunks to discard\"\n \n . git-sh-setup\n \n \n case \"$1\" in\n+ -p|--patch)\n+\tshift\n+\texec git add--interactive --patch=discard \"$@\"\n+\t;;\n --)\n \tif [ $# -eq 1 ]; then\n \t die \"You must specify at least one file to discard changes from\"\ndiff --git a/git-unstage.sh b/git-unstage.sh\nindex 7f99adf..921e12b 100644\n--- a/git-unstage.sh\n+++ b/git-unstage.sh\n@@ -3,13 +3,18 @@\n SUBDIRECTORY_OK=Yes\n OPTIONS_KEEPDASHDASH=\n OPTIONS_SPEC=\"\\\n-git unstage file ...\n---\"\n+git unstage [-p] file ...\n+--\n+p,patch interactively select hunks to unstage\"\n \n . git-sh-setup\n \n \n case \"$1\" in\n+ -p|--patch)\n+\tshift\n+\texec git add--interactive --patch=unstage \"$@\"\n+\t;;\n --)\n \tif [ $# -eq 1 ]; then\n \t die \"You must specify at least one file to unstage\"\n-- \n1.6.4.rc2.217.g74c0b.dirty\n"},{"id":"118639","messageId":"7vocrakpbo.fsf@alter.siamese.dyndns.org","threadId":"20208","inReplyTo":"2d756f643fc7d1b50cf590c95467fa029b49ff46.1248426652.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH] Implement unstage and reset modes for git-add--interactive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-24T16:39:39Z","receivedAt":"2009-07-24T16:39:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> I'm not completely happy with the idea of reset --interactive by the\n> way, as it's not a reset in the 'reset $commit' sense.\n\nWhy not?\n\n\"resetting index entries selectively\" makes perfect sense. So do\n\"checking out index entries selectively\" and \"adding to index\nselectively\".\n"},{"id":"118640","messageId":"1f6632e50907240940j6174a689i4390c245f0771fcb@mail.gmail.com","threadId":"20208","inReplyTo":"9cad6176fe941bd56bad7fed49cc55a96a7040ae.1248452530.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH v2 3/3] Implement unstage --patch and discard --patch","fromName":"Matthias Kestenholz","fromEmail":"mk@feinheit.ch","sentAt":"2009-07-24T16:40:40Z","receivedAt":"2009-07-24T16:40:40Z","isPatch":true,"sender":{"key":"mk@feinheit.ch","avatar":"https://gravatar.com/avatar/f4f02a5336cf0e3d40b05498959e997f023cb5d8c83ab41545a3272268c67949?d=mp&s=160"},"body":"On Fri, Jul 24, 2009 at 6:24 PM, Thomas Rast wrote:\n> This implements a new optional argument --patch= in the\n> git-add--interactive helper.  The modes are:\n>\n> 'stage' (default, as before): offer hunks from 'git diff' and stage\n>  the ones selected by the user.\n>\n> 'unstage': offer hunks from 'git diff --cached', and unstage the ones\n>  selected.\n>\n> 'discard': offer hunks from 'git diff', and discard (i.e., undo the\n>  edit in the working tree) the ones selected.\n>\n> With this in hand, we can then easily add a --patch option to the\n> git-unstage and git-discard scripts that run git-add--interactive in\n> the corresponding modes.\n>\n\nWhile I do not really think even more git commands are so helpful, I\nlike the proposed command names, and I really like that it would be\npossible to remove single hunks from the index. I have come to rely\nvery much on git add -p to make self-contained and clear commits and\nthink it would be a great feature if I could use this the other way\nround too.\n\n\nThanks,\nMatthias\n"},{"id":"118641","messageId":"20090724170622.GA20247@sigill.intra.peff.net","threadId":"20208","inReplyTo":"7v8wienk07.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-24T17:06:22Z","receivedAt":"2009-07-24T17:06:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 24, 2009 at 09:06:16AM -0700, Junio C Hamano wrote:\n\n> In your arsenal, you have \"git add -p\" to help you sift good pieces from\n> other parts in finer grained manner, instead of having to make an all or\n> nothing decision per file basis (i.e. \"git add file\"). But \"git add -p\"\n> (and \"git add -i\") is still about the \"git add\" step in the above high\n> level view. You have a mixture of good and not so good changes in your\n> work tree, and you pick only good pieces to add to the index, _knowing_\n> that you can go back and redo this step safely exactly because your work\n> tree will stay the same even if you did make mistakes.\n> \n> The proposed change breaks this expectation you would have naturally\n> gained during the course of becoming more and more proficient in using\n> git.\n> \n> In other words, I do not think you can say that the change will not harm\n> the experts due to both the points 2 (experts can easily make typo) and 3\n> above (the change breaks the mental model of the world experts would have\n> formed).\n> \n> Having said all that, it indeed would be useful to selectively revert\n> changes from the work tree files.\n\nPerhaps it makes sense to have an interactive stash rather than an\ninteractive revert? Then the reverts that you make are still being saved\nsomewhere, and you can recover from an error by applying the stash. Not\nto mention that interactive stash is useful in its own right.\n\nThe downside is that if you are the sort of person who keeps a clean\nstash list (and I am not such a person), then you have this\n\"to-be-deleted\" cruft on the top of your stash (whereas with a true\nrevert, it just goes away).\n\n-Peff\n"},{"id":"118644","messageId":"36ca99e90907241059l1d06681v1490a89fbbcaaf8@mail.gmail.com","threadId":"20208","inReplyTo":"683ed99f389d643d21bda6750bd2ee9caf287625.1248452530.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH v2 1/3] Introduce git-unstage","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2009-07-24T17:59:34Z","receivedAt":"2009-07-24T17:59:34Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Jul 24, 2009 at 18:24, Thomas Rast wrote:\n> As such, it is the same as 'git reset --' ...\nNope!\n\n> +           exec git reset \"$@\"\nSee!\n\nBert\n"},{"id":"118647","messageId":"36ca99e90907241102v1b261e43yf85ba52754edf869@mail.gmail.com","threadId":"20208","inReplyTo":"36ca99e90907241059l1d06681v1490a89fbbcaaf8@mail.gmail.com","subject":"Re: [RFC PATCH v2 1/3] Introduce git-unstage","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2009-07-24T18:02:21Z","receivedAt":"2009-07-24T18:02:21Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Jul 24, 2009 at 19:59, Bert Wesarg wrote:\n> On Fri, Jul 24, 2009 at 18:24, Thomas Rast wrote:\n>> As such, it is the same as 'git reset --' ...\n> Nope!\n>\n>> +           exec git reset \"$@\"\n> See!\nSorry, it was not obvious clear to me, that you don't shift away '--'.\nDoes the option parsing add '--' if it is missing?\n\nBert\n>\n> Bert\n>\n"},{"id":"118645","messageId":"51419b2c0907241102s31c2fbaeof81e2fb053465c89@mail.gmail.com","threadId":"20208","inReplyTo":"cf51e6aa92ea98fc9409826cc0468a01fdf7b01e.1248452530.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH v2 2/3] Introduce git-discard","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-07-24T18:02:49Z","receivedAt":"2009-07-24T18:02:49Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jul 24, 2009 at 10:24 AM, Thomas Rast wrote:\n> The new command 'git discard' is precisely the same as 'git checkout --'.\n> +(This is the same as `git checkout \\-- `.)\n\nActually, there's an important difference:\n\n> +       exec git checkout \"$@\"\n\n$ git branch foo HEAD~20\n$ touch foo && git add foo\n$ echo hi >> foo\n$ git discard foo\nA foo\nSwitched to branch \"foo\"\n\nYou really do need that \"--\".\n"},{"id":"118646","messageId":"36ca99e90907241108h78881239o403f50773764bd43@mail.gmail.com","threadId":"20208","inReplyTo":"9cad6176fe941bd56bad7fed49cc55a96a7040ae.1248452530.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH v2 3/3] Implement unstage --patch and discard --patch","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2009-07-24T18:08:54Z","receivedAt":"2009-07-24T18:08:54Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Jul 24, 2009 at 18:24, Thomas Rast wrote:\n> 'discard': offer hunks from 'git diff', and discard (i.e., undo the\n>  edit in the working tree) the ones selected.\nGreat, I really miss this feature in git-gui, maybe its easy to add\nthis there too. I may look into this by my self, but not this weekend.\n\nBert\n"},{"id":"118648","messageId":"36ca99e90907241112p6cc2c875q5fa4becd1169bfd3@mail.gmail.com","threadId":"20208","inReplyTo":"51419b2c0907241102s31c2fbaeof81e2fb053465c89@mail.gmail.com","subject":"Re: [RFC PATCH v2 2/3] Introduce git-discard","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2009-07-24T18:12:56Z","receivedAt":"2009-07-24T18:12:56Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Jul 24, 2009 at 20:02, Elijah Newren wrote:\n> On Fri, Jul 24, 2009 at 10:24 AM, Thomas Rast wrote:\n>> The new command 'git discard' is precisely the same as 'git checkout --'.\n>> +(This is the same as `git checkout \\-- `.)\n>\n> Actually, there's an important difference:\n>\n>> +       exec git checkout \"$@\"\n>\n> $ git branch foo HEAD~20\n> $ touch foo && git add foo\n> $ echo hi >> foo\n> $ git discard foo\n> A     foo\n> Switched to branch \"foo\"\n>\n> You really do need that \"--\".\nYou fall into the same trap as me for patch 1/3. He does not shift\naway the '--', so it is still in \"$@\".\n\nBert.\n"},{"id":"118649","messageId":"51419b2c0907241123s4ce39ef0q99a25132429cad61@mail.gmail.com","threadId":"20208","inReplyTo":"683ed99f389d643d21bda6750bd2ee9caf287625.1248452530.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH v2 1/3] Introduce git-unstage","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-07-24T18:23:03Z","receivedAt":"2009-07-24T18:23:03Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jul 24, 2009 at 10:24 AM, Thomas Rast wrote:\n> The new command 'git unstage' is the precise opposite of 'git stage'\n> (i.e., git-add).  As such, it is the same as 'git reset --' unless the\n> current branch is unborn.\n\nI really, really like the idea of being able to do something like\nunstage -p. That's sweet, thanks for working on that.\n\nSome potential issues, though:\n\ngit unstage may cause issues for some people if they try to use it\nwhen in the middle of a merge (why reset back to HEAD rather than one\nof the other branches being merged?). With git reset, one can specify\nwhich commit to reset the index back to. With your 'unstage' command,\nyou not only assume 'HEAD' but don't allow specifying any other value.\n You could add a commit argument here, but that may be problematic\nwording-wise, in that you're allowing to 'unstage' back to a specified\ncommit, with the possibly perplexing result that you have 'staged'\nsomething else.\n\nAlso, you have added two new commands, unstage and discard, which are\ntwo pieces of an hg-like revert (revert edits). We still don't have a\ncommand for a full hg-like revert, though (git checkout does not cover\nthe bases), and to cover that we'd have to add a third command.\nPerhaps the three could be combined?\n\n\nElijah\n"},{"id":"118651","messageId":"51419b2c0907241124q18232290u860c9d7ca7bb374c@mail.gmail.com","threadId":"20208","inReplyTo":"36ca99e90907241112p6cc2c875q5fa4becd1169bfd3@mail.gmail.com","subject":"Re: [RFC PATCH v2 2/3] Introduce git-discard","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-07-24T18:24:51Z","receivedAt":"2009-07-24T18:24:51Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jul 24, 2009 at 12:12 PM, Bert Wesarg wrote:\n> You fall into the same trap as me for patch 1/3. He does not shift\n> away the '--', so it is still in \"$@\".\n\nIndeed; I somehow missed that '--' was silently added by git. I guess\nthat's what I get for shooting off my mouth without actually trying\nit. Sorry for the noise.\n"},{"id":"118662","messageId":"20090725065822.6117@nanako3.lavabit.com","threadId":"20208","inReplyTo":"7vocrakpbo.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] Implement unstage and reset modes for git-add--interactive","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-07-24T21:58:22Z","receivedAt":"2009-07-24T21:58:22Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano \n\n> \"resetting index entries selectively\" makes perfect sense. So do\n> \"checking out index entries selectively\" and \"adding to index\n> selectively\".\n\nAre you saying that you are fine with the concept of Thomas'es patch series but you don't want to see different words used to name these operations?\n\nIn other words, do you mean the following would be a pair of better companions to \"git add -p $file\" than Thomas'es discard and unstage?\n\n - \"git checkout -p $file\" and \"git checkout -p $commit $file\" that let you view the patch to bring the file in the working tree to the version in the index (or the commit) and selectively apply that to the working tree and the index, to implement \"discarding changes selectively\".\n\n - \"git reset -p $file\" and \"git reset -p $commit $file\" that let you view the patch to bring the version of the file in the index to the version in the HEAD (or the commit) and selectively apply that to the index, to implement \"undoing changes made to the index selectively\".\n\nI think it preserves the UI consistency better to enhance checkout and reset than adding new commands to do conceptually the same thing. Unfortunately I don't know how hard the necessary change will be, because these two commands are now implemented in C...\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"118684","messageId":"200907250117.31847.trast@student.ethz.ch","threadId":"20208","inReplyTo":"20090725065822.6117@nanako3.lavabit.com","subject":"Re: [RFC PATCH] Implement unstage and reset modes for git-add--interactive","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-24T23:17:28Z","receivedAt":"2009-07-24T23:17:28Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Nanako Shiraishi wrote:\n> Quoting Junio C Hamano \n> \n> > \"resetting index entries selectively\" makes perfect sense. So do\n> > \"checking out index entries selectively\" and \"adding to index\n> > selectively\".\n> \n> Are you saying that you are fine with the concept of Thomas'es patch\n> series but you don't want to see different words used to name these\n> operations?\n> \n> In other words, do you mean the following would be a pair of better\n> companions to \"git add -p $file\" than Thomas'es discard and unstage?\n> \n> - \"git checkout -p $file\" and \"git checkout -p $commit $file\" [...]\n> - \"git reset -p $file\" and \"git reset -p $commit $file\" [...]\n\nI'd be quite interested to hear some opinions on this. I wasn't sure\nwhat to do and eventually opted for unstage/discard because I felt\n'git checkout -p $file' was not an accurate description of what it\ndoes, but maybe I just have the mental blocks in the wrong places.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"118685","messageId":"7vzlat64u1.fsf@alter.siamese.dyndns.org","threadId":"20208","inReplyTo":"20090725065822.6117@nanako3.lavabit.com","subject":"Re: [RFC PATCH] Implement unstage and reset modes for git-add--interactive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-24T23:25:58Z","receivedAt":"2009-07-24T23:25:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Junio C Hamano \n>\n>> \"resetting index entries selectively\" makes perfect sense. So do\n>> \"checking out index entries selectively\" and \"adding to index\n>> selectively\".\n>\n> Are you saying that you are fine with the concept of Thomas'es patch\n> series but you don't want to see different words used to name these\n> operations?\n\nEssentially, yes.\n\nCould you please wrap your lines to a reasonable length, by the way?\n\n> In other words, do you mean the following would be a pair of better\n> companions to \"git add -p $file\" than Thomas'es discard and unstage?\n>\n> - \"git checkout -p $file\" and \"git checkout -p $commit $file\" that let\n> you view the patch to bring the file in the working tree to the version\n> in the index (or the commit) and selectively apply that to the working\n> tree and the index, to implement \"discarding changes selectively\".\n>\n> - \"git reset -p $file\" and \"git reset -p $commit $file\" that let you\n> view the patch to bring the version of the file in the index to the\n> version in the HEAD (or the commit) and selectively apply that to the\n> index, to implement \"undoing changes made to the index selectively\".\n>\n> I think it preserves the UI consistency better to enhance checkout and\n> reset than adding new commands to do conceptually the same\n> thing...\n\nI didn't read Thomas's series beyond the cover letter, but I'd say the\nabove three (counting \"add -p\" in the mix) extends the existing concepts\nin a natural way:\n\n - \"add\" goes from work tree to the index;\n\n - \"checkout\" goes from commit or index to the work tree; and\n\n - \"reset\" goes from commit to index.\n\nThe \"-p\" variant (which exists to \"add\" but new to \"checkout\" and \"reset\")\nallows you to do these movements in a finer grained manner than per\nwhole-file.\n\n> ... Unfortunately I don't know how hard the necessary change will be,\n> because these two commands are now implemented in C...\n\nThat's OK. There are others on the list who groks C, like Thomas ;-)\n"},{"id":"118698","messageId":"7v1vo537m0.fsf@alter.siamese.dyndns.org","threadId":"20208","inReplyTo":"20090724170622.GA20247@sigill.intra.peff.net","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-25T00:54:15Z","receivedAt":"2009-07-25T00:54:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Perhaps it makes sense to have an interactive stash rather than an\n> interactive revert? Then the reverts that you make are still being saved\n> somewhere, and you can recover from an error by applying the stash. Not\n> to mention that interactive stash is useful in its own right.\n>\n> The downside is that if you are the sort of person who keeps a clean\n> stash list (and I am not such a person), then you have this\n> \"to-be-deleted\" cruft on the top of your stash (whereas with a true\n> revert, it just goes away).\n\nYeah, such a stash entry would be more like \"trash can\". It is not\n\"to-be-deleted\" but \"have been deleted, but you _could_ resurrect\".\n\nIt may not be a bad idea to do it that way, or perhaps \"git checkout -p\"\ncan automatically create such a trash can while undoing the local changes\nin the work tree.\n"},{"id":"118708","messageId":"200907251135.33164.trast@student.ethz.ch","threadId":"20208","inReplyTo":"7v1vo537m0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-25T09:35:31Z","receivedAt":"2009-07-25T09:35:31Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> \n> Yeah, such a stash entry would be more like \"trash can\". It is not\n> \"to-be-deleted\" but \"have been deleted, but you _could_ resurrect\".\n> \n> It may not be a bad idea to do it that way, or perhaps \"git checkout -p\"\n> can automatically create such a trash can while undoing the local changes\n> in the work tree.\n\nI'd rather implement this as part of the generic \"worktree/index log\"\nthat was proposed a while back, where any index- or\nworktree-overwriting operation that actually discards data would save\nthe lost state in a special reflog. That way people won't complain\nbecause 'git checkout -p -- $file' saved their state, but\n'git checkout -- $file' didn't, even though they should be equivalent.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"118726","messageId":"20090725144803.GA18545@artemis.corp","threadId":"20208","inReplyTo":"20090724170622.GA20247@sigill.intra.peff.net","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-07-25T14:48:03Z","receivedAt":"2009-07-25T14:48:03Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Fri, Jul 24, 2009 at 01:06:22PM -0400, Jeff King wrote:\n> On Fri, Jul 24, 2009 at 09:06:16AM -0700, Junio C Hamano wrote:\n> \n> > In your arsenal, you have \"git add -p\" to help you sift good pieces from\n> > other parts in finer grained manner, instead of having to make an all or\n> > nothing decision per file basis (i.e. \"git add file\"). But \"git add -p\"\n> > (and \"git add -i\") is still about the \"git add\" step in the above high\n> > level view. You have a mixture of good and not so good changes in your\n> > work tree, and you pick only good pieces to add to the index, _knowing_\n> > that you can go back and redo this step safely exactly because your work\n> > tree will stay the same even if you did make mistakes.\n> > \n> > The proposed change breaks this expectation you would have naturally\n> > gained during the course of becoming more and more proficient in using\n> > git.\n> > \n> > In other words, I do not think you can say that the change will not harm\n> > the experts due to both the points 2 (experts can easily make typo) and 3\n> > above (the change breaks the mental model of the world experts would have\n> > formed).\n> > \n> > Having said all that, it indeed would be useful to selectively revert\n> > changes from the work tree files.\n> \n> Perhaps it makes sense to have an interactive stash rather than an\n> interactive revert?\n\nVery cool idea, it's even better than creating a revert patch.\n\nNote that to undermine the \"dirty stash list\" effect we could have\nquite easily different stash queues if it's badly needed, so it sounds\nlike a moot point to me.\n-- \nIntersec \nPierre Habouzit \nTél : +33 (0)1 5570 3346\nMob : +33 (0)6 1636 8131\nFax : +33 (0)1 5570 3332\n37 Rue Pierre Lhomme\n92400 Courbevoie\n"},{"id":"118727","messageId":"20090725145237.GB18545@artemis.corp","threadId":"20208","inReplyTo":"7v8wienk07.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add -p: be able to undo a given hunk","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-07-25T14:52:37Z","receivedAt":"2009-07-25T14:52:37Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Fri, Jul 24, 2009 at 09:06:16AM -0700, Junio C Hamano wrote:\n> Even though you could add good bits interactively, making multiple\n> commits, and remove the remaining debugging cruft at the very end with\n> \"git checkout $files\" or \"git reset --hard\", if there are debugging crufts\n> for two or more phases of development,\n\nFWIW it's what I was doing so far, and it's not very efficient for many\npatterns, you talked about the bit where you want to keep some of the\ndebug, for this one I used to do that:\n\nwhile I have meaning full commits to do:\n git add -p; commit;\ngit add -p the things I want to trash and commit\ngit stash\ngit reset --hard HEAD~1\ngit stash apply\n\nThat sucks.\n\nAnother thing is that: if you have _many_ commits to do, you have to\nrefuse the same hunks (or worse edit) all over the place. That's awful.\nWith an \"undo\", you look at them once only. That's a lot of thinking\nsaved, and when you have a lot of hunks, less chances to mess an answer\n(who here hasn't typed 'y' where he meant 'n' at least once ...)\n\n\nFor all those reasons I believe it's a good thing to be able to have\nsomething to remove hunks from the working-directory. Jeff's suggestions\nto move them to some stash is the best suggestion so far, and is safe.\n\n-- \nIntersec \nPierre Habouzit \nTél : +33 (0)1 5570 3346\nMob : +33 (0)6 1636 8131\nFax : +33 (0)1 5570 3332\n37 Rue Pierre Lhomme\n92400 Courbevoie\n"},{"id":"118728","messageId":"20090725145819.GC18545@artemis.corp","threadId":"20208","inReplyTo":"cf51e6aa92ea98fc9409826cc0468a01fdf7b01e.1248452530.git.trast@student.ethz.ch","subject":"Re: [RFC PATCH v2 2/3] Introduce git-discard","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-07-25T14:58:20Z","receivedAt":"2009-07-25T14:58:20Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Fri, Jul 24, 2009 at 06:24:35PM +0200, Thomas Rast wrote:\n> +*WARNING:* All unstaged changes to the 'paths' are *irreversibly*\n> +lost.\n\nFWIW, as git checkout -- is already doing that, and that\ngit-discard is clearly something meant as some UI sugar, I would make\nthat operation a \"safe\" porcelain by puting the discarded hunks in a\nstash.\n\nI'm shamelessly stealing this idea from Jeff, but it's probably an\nexcellent idea to have a strash¹. It makes git even safer to use,\nespecially to beginners, to whom we would talk about git-discard instead\nof git checkout.\n\n¹: stash-trash\n-- \nIntersec \nPierre Habouzit \nTél : +33 (0)1 5570 3346\nMob : +33 (0)6 1636 8131\nFax : +33 (0)1 5570 3332\n37 Rue Pierre Lhomme\n92400 Courbevoie\n"},{"id":"118788","messageId":"cover.1248557241.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"7vzlat64u1.fsf@alter.siamese.dyndns.org","subject":"[RFC PATCH v3 0/5] {checkout,reset,stash} --patch","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-25T21:29:29Z","receivedAt":"2009-07-25T21:29:29Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> > ... Unfortunately I don't know how hard the necessary change will be,\n> > because these two commands are now implemented in C...\n> \n> That's OK. There are others on the list who groks C, like Thomas ;-)\n\nWell, then let's see if your trust is justified ;-)\n\n> - \"add\" goes from work tree to the index;\n> \n> - \"reset\" goes from commit to index.\n\nLuckily \"reset\" is exactly symmetrical to \"add\", so that's not too\nhard.\n\n> - \"checkout\" goes from commit or index to the work tree; and\n\nUnfortunately there are some subtleties here. In the 'git checkout\nHEAD -- $file' case, we overwrite both worktree and index. So\nmorally, if you select a hunk for checking out it should be reverse\napplied to both, too. However, that may not always be possible.\n\n[One possible change to checkout -p would be to reverse the direction\nof hunks as shown. Currently it's more in the \"discard\" spirit: you\nmade the change shown in this hunk, saying 'y' will throw this change\naway.]\n\nSimilarly, \"stash\" has some problems: we want to encode the changes\nHEAD..index into one commit, and index..worktree into another.\nHowever, these patches may not apply on top of each other depending on\nwhat hunks were selected. I see three options:\n\n* Make more a priori restrictions, such as, --patch is strictly about\n the worktree and simply refuses to stash anything if you have staged\n changes; or, we only deal with the worktree and always stash the\n index whole. I think at least the first option would make it\n significantly less useful though.\n\n* Hope that it works out, and catch failure later. This is what it\n currently does.\n\n* Expand the stash format to four commits so that, e.g.,\n stash^1..stash^2 is HEAD..index and stash^3..stash is\n index..worktree. (Currently stash^1 is HEAD, stash^2 is index and\n stash is worktree.) This would require more changes, and make these\n stashes backward incompatible w.r.t. application, so I'm not sure it\n is worth the trouble.\n\nYeah, there still aren't any tests, sorry. I'm not sure I will get\naround to it this weekend, but then it's -rc anyway and we're in no\nhurry.\n\n\nThomas Rast (5):\n git-apply--interactive: Refactor patch mode code\n builtin-add: refactor the meat of interactive_add()\n Implement 'git reset --patch'\n Implement 'git checkout --patch'\n Implement 'git stash save --patch'\n\n Documentation/git-checkout.txt | 13 +++-\n Documentation/git-reset.txt | 15 +++-\n Documentation/git-stash.txt | 10 ++-\n builtin-add.c | 43 ++++++---\n builtin-checkout.c | 19 ++++\n builtin-reset.c | 15 +++\n commit.h | 2 +\n git-add--interactive.perl | 189 +++++++++++++++++++++++++++++++++-------\n git-stash.sh | 120 +++++++++++++++++++++-----\n 9 files changed, 355 insertions(+), 71 deletions(-)\n"},{"id":"118791","messageId":"4392f03ec6461f51133a10c4c74d2fda55e84cff.1248557241.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"cover.1248557241.git.trast@student.ethz.ch","subject":"[RFC PATCH v3 1/5] git-apply--interactive: Refactor patch mode code","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-25T21:29:30Z","receivedAt":"2009-07-25T21:29:30Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"This makes some aspects of the 'git add -p' loop configurable (within\nthe code), so that we can later reuse git-add--interactive for other\nsimilar tools.\n\nMost fields are fairly straightforward, but APPLY gets a subroutine\n(instead of just a string a la 'apply --cached') so that we can handle\n'checkout -p', which will need to atomically apply the patch twice\n(index and worktree).\n\nSigned-off-by: Thomas Rast \n---\n git-add--interactive.perl | 79 +++++++++++++++++++++++++++++---------------\n 1 files changed, 52 insertions(+), 27 deletions(-)\n\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex df9f231..58c3332 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -73,6 +73,21 @@\n # command line options\n my $patch_mode;\n \n+sub apply_patch;\n+\n+my %patch_modes = (\n+\t'stage' => {\n+\t\tDIFF => 'diff-files -p',\n+\t\tAPPLY => sub { apply_patch 'apply --cached', @_; },\n+\t\tAPPLY_CHECK => 'apply --cached',\n+\t\tVERB => 'Stage',\n+\t\tPARTICIPLE => 'staging',\n+\t\tFILTER => 'file-only',\n+\t},\n+);\n+\n+my %patch_mode_flavour = %{$patch_modes{stage}};\n+\n sub run_cmd_pipe {\n \tif ($^O eq 'MSWin32' || $^O eq 'msys') {\n \t\tmy @invalid = grep {m/[\":*]/} @_;\n@@ -613,12 +628,21 @@\n \tprint \"\\n\";\n }\n \n+sub run_git_apply {\n+\tmy $cmd = shift;\n+\tmy $fh;\n+\topen $fh, '| git ' . $cmd;\n+\tprint $fh @_;\n+\treturn close $fh;\n+}\n+\n sub parse_diff {\n \tmy ($path) = @_;\n-\tmy @diff = run_cmd_pipe(qw(git diff-files -p --), $path);\n+\tmy @diff_cmd = split(\" \", $patch_mode_flavour{DIFF});\n+\tmy @diff = run_cmd_pipe(\"git\", @diff_cmd, \"--\", $path);\n \tmy @colored = ();\n \tif ($diff_use_color) {\n-\t\t@colored = run_cmd_pipe(qw(git diff-files -p --color --), $path);\n+\t\t@colored = run_cmd_pipe(\"git\", @diff_cmd, qw(--color --), $path);\n \t}\n \tmy (@hunk) = { TEXT => [], DISPLAY => [], TYPE => 'header' };\n \n@@ -877,6 +901,7 @@\n \t\tor die \"failed to open hunk edit file for writing: \" . $!;\n \tprint $fh \"# Manual hunk edit mode -- see bottom for a quick guide\\n\";\n \tprint $fh @$oldtext;\n+\tmy $participle = $patch_mode_flavour{PARTICIPLE};\n \tprint $fh <{TEXT}};\n-\t}\n-\treturn close $fh;\n+\treturn run_git_apply($patch_mode_flavour{APPLY_CHECK} . ' --recount --check',\n+\t\t\t map { @{$_->{TEXT}} } @_);\n }\n \n sub _restore_terminal_and_die {\n@@ -988,12 +1010,13 @@\n }\n \n sub help_patch_cmd {\n-\tprint colored $help_color, <<\\EOF ;\n-y - stage this hunk\n-n - do not stage this hunk\n-q - quit, do not stage this hunk nor any of the remaining ones\n-a - stage this and all the remaining hunks in the file\n-d - do not stage this hunk nor any of the remaining hunks in the file\n+\tmy $verb = lc $patch_mode_flavour{VERB};\n+\tprint colored $help_color, <{BINARY}) } @all_mods;\n \tmy @them;\n \n@@ -1138,8 +1170,8 @@\n \t\tfor (@{$hunk[$ix]{DISPLAY}}) {\n \t\t\tprint;\n \t\t}\n-\t\tprint colored $prompt_color, 'Stage ',\n-\t\t ($hunk[$ix]{TYPE} eq 'mode' ? 'mode change' : 'this hunk'),\n+\t\tprint colored $prompt_color, $patch_mode_flavour{VERB},\n+\t\t ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' : ' this hunk'),\n \t\t \" [y,n,q,a,d,/$other,?]? \";\n \t\tmy $line = prompt_single_character;\n \t\tif ($line) {\n@@ -1313,16 +1345,9 @@\n \n \tif (@result) {\n \t\tmy $fh;\n-\n-\t\topen $fh, '| git apply --cached --recount';\n-\t\tfor (@{$head->{TEXT}}, @result) {\n-\t\t\tprint $fh $_;\n-\t\t}\n-\t\tif (!close $fh) {\n-\t\t\tfor (@{$head->{TEXT}}, @result) {\n-\t\t\t\tprint STDERR $_;\n-\t\t\t}\n-\t\t}\n+\t\tmy @patch = (@{$head->{TEXT}}, @result);\n+\t\tmy $apply_routine = $patch_mode_flavour{APPLY};\n+\t\t&$apply_routine(@patch);\n \t\trefresh();\n \t}\n \n-- \n1.6.4.rc2.227.gf5e17\n"},{"id":"118786","messageId":"35bee46b2361c0af841bbc844ce2f76c3ebbeb3e.1248557241.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"cover.1248557241.git.trast@student.ethz.ch","subject":"[RFC PATCH v3 2/5] builtin-add: refactor the meat of interactive_add()","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-25T21:29:31Z","receivedAt":"2009-07-25T21:29:31Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"This moves the call setup for 'git add--interactive' to a separate\nfunction, as other users will call it without running\nvalidate_pathspec() first.\n\nSigned-off-by: Thomas Rast \n---\n builtin-add.c | 43 +++++++++++++++++++++++++++++--------------\n commit.h | 2 ++\n 2 files changed, 31 insertions(+), 14 deletions(-)\n\ndiff --git a/builtin-add.c b/builtin-add.c\nindex 581a2a1..c422a62 100644\n--- a/builtin-add.c\n+++ b/builtin-add.c\n@@ -131,27 +131,27 @@ static void refresh(int verbose, const char **pathspec)\n \treturn pathspec;\n }\n \n-int interactive_add(int argc, const char **argv, const char *prefix)\n+int run_add_interactive(const char *revision, const char *patch_mode,\n+\t\t\tconst char **pathspec)\n {\n-\tint status, ac;\n+\tint status, ac, pc = 0;\n \tconst char **args;\n-\tconst char **pathspec = NULL;\n \n-\tif (argc) {\n-\t\tpathspec = validate_pathspec(argc, argv, prefix);\n-\t\tif (!pathspec)\n-\t\t\treturn -1;\n-\t}\n+\tif (pathspec)\n+\t\twhile (pathspec[pc])\n+\t\t\tpc++;\n \n-\targs = xcalloc(sizeof(const char *), (argc + 4));\n+\targs = xcalloc(sizeof(const char *), (pc + 5));\n \tac = 0;\n \targs[ac++] = \"add--interactive\";\n-\tif (patch_interactive)\n-\t\targs[ac++] = \"--patch\";\n+\tif (patch_mode)\n+\t\targs[ac++] = patch_mode;\n+\tif (revision)\n+\t\targs[ac++] = revision;\n \targs[ac++] = \"--\";\n-\tif (argc) {\n-\t\tmemcpy(&(args[ac]), pathspec, sizeof(const char *) * argc);\n-\t\tac += argc;\n+\tif (pc) {\n+\t\tmemcpy(&(args[ac]), pathspec, sizeof(const char *) * pc);\n+\t\tac += pc;\n \t}\n \targs[ac] = NULL;\n \n@@ -160,6 +160,21 @@ int interactive_add(int argc, const char **argv, const char *prefix)\n \treturn status;\n }\n \n+int interactive_add(int argc, const char **argv, const char *prefix)\n+{\n+\tconst char **pathspec = NULL;\n+\n+\tif (argc) {\n+\t\tpathspec = validate_pathspec(argc, argv, prefix);\n+\t\tif (!pathspec)\n+\t\t\treturn -1;\n+\t}\n+\n+\treturn run_add_interactive(NULL,\n+\t\t\t\t patch_interactive ? \"--patch\" : NULL,\n+\t\t\t\t pathspec);\n+}\n+\n static int edit_patch(int argc, const char **argv, const char *prefix)\n {\n \tchar *file = xstrdup(git_path(\"ADD_EDIT.patch\"));\ndiff --git a/commit.h b/commit.h\nindex 8bfdf0e..0555e80 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -139,6 +139,8 @@ struct commit_graft {\n int in_merge_bases(struct commit *, struct commit **, int);\n \n extern int interactive_add(int argc, const char **argv, const char *prefix);\n+extern int run_add_interactive(const char *revision, const char *patch_mode,\n+\t\t\t const char **pathspec);\n \n static inline int single_parent(struct commit *commit)\n {\n-- \n1.6.4.rc2.227.gf5e17\n"},{"id":"118787","messageId":"9a85f03f0205fd97ee9dd11d1f11c94be063aa40.1248557241.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"cover.1248557241.git.trast@student.ethz.ch","subject":"[RFC PATCH v3 3/5] Implement 'git reset --patch'","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-25T21:29:32Z","receivedAt":"2009-07-25T21:29:32Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"This introduces a --patch mode for git-reset. The basic case is\n\n git reset --patch -- [files...]\n\nwhich acts as the opposite of 'git add --patch -- [files...]': it\noffers hunks for *un*staging. Advanced usage is\n\n git reset --patch -- [files...]\n\nwhich offers hunks from the diff between and the index for\nreverse application to the index. (That is, the basic case is just\n = HEAD.) This means it can be used to \"undo\" changes since\n in the index, but may be slightly confusing when \nis logically \"newer\" than the index state.\n\nSigned-off-by: Thomas Rast \n---\n Documentation/git-reset.txt | 15 +++++++++++++--\n builtin-reset.c | 15 +++++++++++++++\n git-add--interactive.perl | 36 +++++++++++++++++++++++++++++++++---\n 3 files changed, 61 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt\nindex abb25d1..469cf6d 100644\n--- a/Documentation/git-reset.txt\n+++ b/Documentation/git-reset.txt\n@@ -10,6 +10,7 @@ SYNOPSIS\n [verse]\n 'git reset' [--mixed | --soft | --hard | --merge] [-q] []\n 'git reset' [-q] [] [--] ...\n+'git reset' --patch [] [--] [...]\n \n DESCRIPTION\n -----------\n@@ -23,8 +24,9 @@ the undo in the history.\n If you want to undo a commit other than the latest on a branch,\n linkgit:git-revert[1] is your friend.\n \n-The second form with 'paths' is used to revert selected paths in\n-the index from a given commit, without moving HEAD.\n+The second and third forms with 'paths' and/or --patch are used to\n+revert selected paths in the index from a given commit, without moving\n+HEAD.\n \n \n OPTIONS\n@@ -50,6 +52,15 @@ OPTIONS\n \tand updates the files that are different between the named commit\n \tand the current commit in the working tree.\n \n+-p::\n+--patch::\n+\tInteractively select hunks in the difference between the index\n+\tand (defaults to HEAD). The chosen hunks are applied\n+\tin reverse to the index.\n++\n+This means that `git reset -p` is the opposite of `git add -p` (see\n+linkgit:git-add[1]).\n+\n -q::\n \tBe quiet, only report errors.\n \ndiff --git a/builtin-reset.c b/builtin-reset.c\nindex 5fa1789..e4fef5d 100644\n--- a/builtin-reset.c\n+++ b/builtin-reset.c\n@@ -142,6 +142,13 @@ static void update_index_from_diff(struct diff_queue_struct *q,\n \t}\n }\n \n+static int interactive_reset(const char *revision, const char **argv,\n+\t\t\t const char *prefix)\n+{\n+\treturn run_add_interactive(revision, \"--patch=reset\",\n+\t\t\t\t get_pathspec(prefix, argv));\n+}\n+\n static int read_from_tree(const char *prefix, const char **argv,\n \t\tunsigned char *tree_sha1, int refresh_flags)\n {\n@@ -183,6 +190,7 @@ static void prepend_reflog_action(const char *action, char *buf, size_t size)\n int cmd_reset(int argc, const char **argv, const char *prefix)\n {\n \tint i = 0, reset_type = NONE, update_ref_status = 0, quiet = 0;\n+\tint patch_mode = 0;\n \tconst char *rev = \"HEAD\";\n \tunsigned char sha1[20], *orig = NULL, sha1_orig[20],\n \t\t\t\t*old_orig = NULL, sha1_old_orig[20];\n@@ -198,6 +206,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\t\t\t\"reset HEAD, index and working tree\", MERGE),\n \t\tOPT_BOOLEAN('q', NULL, &quiet,\n \t\t\t\t\"disable showing new HEAD in hard reset and progress message\"),\n+\t\tOPT_BOOLEAN('p', \"patch\", &patch_mode, \"select hunks interactively\"),\n \t\tOPT_END()\n \t};\n \n@@ -251,6 +260,12 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\tdie(\"Could not parse object '%s'.\", rev);\n \thashcpy(sha1, commit->object.sha1);\n \n+\tif (patch_mode) {\n+\t\tif (reset_type != NONE)\n+\t\t\tdie(\"--patch is incompatible with --{hard,mixed,soft}\");\n+\t\treturn interactive_reset(rev, argv, prefix);\n+\t}\n+\n \t/* git reset tree [--] paths... can be used to\n \t * load chosen paths from the tree into the index without\n \t * affecting the working tree nor HEAD. */\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex 58c3332..b1aa846 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -72,6 +72,7 @@\n \n # command line options\n my $patch_mode;\n+my $patch_mode_revision;\n \n sub apply_patch;\n \n@@ -84,6 +85,14 @@\n \t\tPARTICIPLE => 'staging',\n \t\tFILTER => 'file-only',\n \t},\n+\t'reset' => {\n+\t\tDIFF => 'diff-index -p --cached',\n+\t\tAPPLY => sub { apply_patch 'apply -R --cached', @_; },\n+\t\tAPPLY_CHECK => 'apply -R --cached',\n+\t\tVERB => 'Reset',\n+\t\tPARTICIPLE => 'resetting',\n+\t\tFILTER => 'index-only',\n+\t},\n );\n \n my %patch_mode_flavour = %{$patch_modes{stage}};\n@@ -639,6 +648,9 @@\n sub parse_diff {\n \tmy ($path) = @_;\n \tmy @diff_cmd = split(\" \", $patch_mode_flavour{DIFF});\n+\tif (defined $patch_mode_revision) {\n+\t\tpush @diff_cmd, $patch_mode_revision;\n+\t}\n \tmy @diff = run_cmd_pipe(\"git\", @diff_cmd, \"--\", $path);\n \tmy @colored = ();\n \tif ($diff_use_color) {\n@@ -1388,11 +1400,29 @@\n sub process_args {\n \treturn unless @ARGV;\n \tmy $arg = shift @ARGV;\n-\tif ($arg eq \"--patch\") {\n-\t\t$patch_mode = 1;\n-\t\t$arg = shift @ARGV or die \"missing --\";\n+\tif ($arg =~ /--patch(?:=(.*))?/) {\n+\t\tif (defined $1) {\n+\t\t\tif ($1 eq 'reset') {\n+\t\t\t\t$patch_mode = 'reset';\n+\t\t\t\t$patch_mode_revision = 'HEAD';\n+\t\t\t\t$arg = shift @ARGV or die \"missing --\";\n+\t\t\t\tif ($arg ne '--') {\n+\t\t\t\t\t$patch_mode_revision = $arg;\n+\t\t\t\t\t$arg = shift @ARGV or die \"missing --\";\n+\t\t\t\t}\n+\t\t\t} elsif ($1 eq 'stage') {\n+\t\t\t\t$patch_mode = 'stage';\n+\t\t\t\t$arg = shift @ARGV or die \"missing --\";\n+\t\t\t} else {\n+\t\t\t\tdie \"unknown --patch mode: $1\";\n+\t\t\t}\n+\t\t} else {\n+\t\t\t$patch_mode = 'stage';\n+\t\t\t$arg = shift @ARGV or die \"missing --\";\n+\t\t}\n \t\tdie \"invalid argument $arg, expecting --\"\n \t\t unless $arg eq \"--\";\n+\t\t%patch_mode_flavour = %{$patch_modes{$patch_mode}};\n \t}\n \telsif ($arg ne \"--\") {\n \t\tdie \"invalid argument $arg, expecting --\";\n-- \n1.6.4.rc2.227.gf5e17\n"},{"id":"118790","messageId":"93da49abd5fc514906bac73553d6802eb7fb69fd.1248557241.git.trast@student.ethz.ch","threadId":"20208","inReplyTo":"cover.1248557241.git.trast@student.ethz.ch","subject":"[RFC PATCH v3 4/5] Implement 'git checkout --patch'","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-07-25T21:29:33Z","receivedAt":"2009-07-25T21:29:33Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"This introduces a --patch mode for git-checkout. In the index usage\n\n git checkout --patch -- [files...]\n\nit lets the user discard edits from the at the granularity of\nhunks (by selecting hunks from 'git diff' and then reverse applying\nthem to the worktree).\n\nWe also accept a revision argument\n\n git checkout --patch -- [files...]\n\nwhich offers hunks from the difference between the and the\nworktree. The chosen hunks are then reverse applied to both index and\nworktree, discarding them completely. This application is done\n\"atomically\" in the sense that we first check if the patch applies to\nthe index (it should always apply to the worktree). If it does not,\nwe give the user a choice to either abort or apply to the worktree\nanyway.\n\nSigned-off-by: Thomas Rast \n---\n Documentation/git-checkout.txt | 13 ++++++++++-\n builtin-checkout.c | 19 +++++++++++++++\n git-add--interactive.perl | 48 ++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 79 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex ad4b31e..26a5447 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -11,6 +11,7 @@ SYNOPSIS\n 'git checkout' [-q] [-f] [-m] []\n 'git checkout' [-q] [-f] [-m] [-b ] []\n 'git checkout' [-f|--ours|--theirs|-m|--conflict=