{"thread":{"id":"10672","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","startedAt":"2007-11-05T19:01:41Z","lastAt":"2007-11-07T20:01:53Z","messageCount":39,"participants":["Pierre Habouzit","J. Bruce Fields","Steven Grimm","Alejandro Martinez Ruiz","David Kastrup","Junio C Hamano","Johannes Schindelin","Mike Hommey","Johannes Sixt","Wincent Colaiuta","Robin Rosenberg","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"299027","messageId":"1194289301-7800-1-git-send-email-madcoder@debian.org","threadId":"10672","inReplyTo":null,"subject":"[PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-05T19:01:41Z","receivedAt":"2007-11-05T19:01:41Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"When git-revert has a file argument then redirect the user to what he\nprobably meant.\n\nSigned-off-by: Pierre Habouzit \n---\n builtin-revert.c | 24 +++++++++++++++++-------\n gitk | 2 +-\n 2 files changed, 18 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin-revert.c b/builtin-revert.c\nindex 62ab1fa..9660048 100644\n--- a/builtin-revert.c\n+++ b/builtin-revert.c\n@@ -38,7 +38,7 @@ static const char *me;\n \n #define GIT_REFLOG_ACTION \"GIT_REFLOG_ACTION\"\n \n-static void parse_args(int argc, const char **argv)\n+static void parse_args(int argc, const char **argv, const char *prefix)\n {\n \tconst char * const * usage_str =\n \t\taction == REVERT ? revert_usage : cherry_pick_usage;\n@@ -58,8 +58,18 @@ static void parse_args(int argc, const char **argv)\n \t\tusage_with_options(usage_str, options);\n \targ = argv[0];\n \n-\tif (get_sha1(arg, sha1))\n-\t\tdie (\"Cannot find '%s'\", arg);\n+\tif (get_sha1(arg, sha1)) {\n+\t\tstruct stat st;\n+\t\tconst char *name;\n+\n+\t\tname = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;\n+\t\tif (!lstat(name, &st)) {\n+\t\t\tdie(\"Cannot find commit '%s', did you meant: \"\n+\t\t\t\t\"git checkout HEAD -- '%s'\", arg, arg);\n+\t\t} else {\n+\t\t\tdie(\"Cannot find commit '%s'\", arg);\n+\t\t}\n+\t}\n \tcommit = (struct commit *)parse_object(sha1);\n \tif (!commit)\n \t\tdie (\"Could not find %s\", sha1_to_hex(sha1));\n@@ -225,7 +235,7 @@ static int merge_recursive(const char *base_sha1,\n \treturn run_command_v_opt(argv, RUN_COMMAND_NO_STDIN | RUN_GIT_CMD);\n }\n \n-static int revert_or_cherry_pick(int argc, const char **argv)\n+static int revert_or_cherry_pick(int argc, const char **argv, const char *prefix)\n {\n \tunsigned char head[20];\n \tstruct commit *base, *next, *parent;\n@@ -237,7 +247,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)\n \tgit_config(git_default_config);\n \tme = action == REVERT ? \"revert\" : \"cherry-pick\";\n \tsetenv(GIT_REFLOG_ACTION, me, 0);\n-\tparse_args(argc, argv);\n+\tparse_args(argc, argv, prefix);\n \n \t/* this is copied from the shell script, but it's never triggered... */\n \tif (action == REVERT && !no_replay)\n@@ -405,12 +415,12 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n \t\tedit = 1;\n \tno_replay = 1;\n \taction = REVERT;\n-\treturn revert_or_cherry_pick(argc, argv);\n+\treturn revert_or_cherry_pick(argc, argv, prefix);\n }\n \n int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n {\n \tno_replay = 0;\n \taction = CHERRY_PICK;\n-\treturn revert_or_cherry_pick(argc, argv);\n+\treturn revert_or_cherry_pick(argc, argv, prefix);\n }\ndiff --git a/gitk b/gitk\nindex 1da0b0a..ab8bab2 100755\n--- a/gitk\n+++ b/gitk\n@@ -1,6 +1,6 @@\n #!/bin/sh\n # Tcl ignores the next line -*- tcl -*- \\\n-exec wish \"$0\" -- \"$@\"\n+exec wish8.5 \"$0\" -- \"$@\"\n \n # Copyright (C) 2005-2006 Paul Mackerras. All rights reserved.\n # This program is free software; it may be used, copied, modified\n-- \n1.5.3.5.1541.gd2b5c-dirty\n\n"},{"id":"58399","messageId":"20071105190411.GG6205@artemis.corp","threadId":"10672","inReplyTo":"1194289301-7800-1-git-send-email-madcoder@debian.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-05T19:04:11Z","receivedAt":"2007-11-05T19:04:11Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 05, 2007 at 07:01:41PM +0000, Pierre Habouzit wrote:\n> When git-revert has a file argument then redirect the user to what he\n> probably meant.\n> \n> Signed-off-by: Pierre Habouzit \n> ---\n> builtin-revert.c | 24 +++++++++++++++++-------\n> gitk | 2 +-\n> 2 files changed, 18 insertions(+), 8 deletions(-)\n> \n> diff --git a/builtin-revert.c b/builtin-revert.c\n> index 62ab1fa..9660048 100644\n> --- a/builtin-revert.c\n> +++ b/builtin-revert.c\n> @@ -38,7 +38,7 @@ static const char *me;\n> \n> #define GIT_REFLOG_ACTION \"GIT_REFLOG_ACTION\"\n> \n> -static void parse_args(int argc, const char **argv)\n> +static void parse_args(int argc, const char **argv, const char *prefix)\n> {\n> \tconst char * const * usage_str =\n> \t\taction == REVERT ? revert_usage : cherry_pick_usage;\n> @@ -58,8 +58,18 @@ static void parse_args(int argc, const char **argv)\n> \t\tusage_with_options(usage_str, options);\n> \targ = argv[0];\n> \n> -\tif (get_sha1(arg, sha1))\n> -\t\tdie (\"Cannot find '%s'\", arg);\n> +\tif (get_sha1(arg, sha1)) {\n> +\t\tstruct stat st;\n> +\t\tconst char *name;\n> +\n> +\t\tname = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;\n> +\t\tif (!lstat(name, &st)) {\n> +\t\t\tdie(\"Cannot find commit '%s', did you meant: \"\n> +\t\t\t\t\"git checkout HEAD -- '%s'\", arg, arg);\n> +\t\t} else {\n> +\t\t\tdie(\"Cannot find commit '%s'\", arg);\n> +\t\t}\n> +\t}\n> \tcommit = (struct commit *)parse_object(sha1);\n> \tif (!commit)\n> \t\tdie (\"Could not find %s\", sha1_to_hex(sha1));\n> @@ -225,7 +235,7 @@ static int merge_recursive(const char *base_sha1,\n> \treturn run_command_v_opt(argv, RUN_COMMAND_NO_STDIN | RUN_GIT_CMD);\n> }\n> \n> -static int revert_or_cherry_pick(int argc, const char **argv)\n> +static int revert_or_cherry_pick(int argc, const char **argv, const char *prefix)\n> {\n> \tunsigned char head[20];\n> \tstruct commit *base, *next, *parent;\n> @@ -237,7 +247,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)\n> \tgit_config(git_default_config);\n> \tme = action == REVERT ? \"revert\" : \"cherry-pick\";\n> \tsetenv(GIT_REFLOG_ACTION, me, 0);\n> -\tparse_args(argc, argv);\n> +\tparse_args(argc, argv, prefix);\n> \n> \t/* this is copied from the shell script, but it's never triggered... */\n> \tif (action == REVERT && !no_replay)\n> @@ -405,12 +415,12 @@ int cmd_revert(int argc, const char **argv, const char *prefix)\n> \t\tedit = 1;\n> \tno_replay = 1;\n> \taction = REVERT;\n> -\treturn revert_or_cherry_pick(argc, argv);\n> +\treturn revert_or_cherry_pick(argc, argv, prefix);\n> }\n> \n> int cmd_cherry_pick(int argc, const char **argv, const char *prefix)\n> {\n> \tno_replay = 0;\n> \taction = CHERRY_PICK;\n> -\treturn revert_or_cherry_pick(argc, argv);\n> +\treturn revert_or_cherry_pick(argc, argv, prefix);\n> }\n\n\n\n\n> diff --git a/gitk b/gitk\n> index 1da0b0a..ab8bab2 100755\n> --- a/gitk\n> +++ b/gitk\n> @@ -1,6 +1,6 @@\n> #!/bin/sh\n> # Tcl ignores the next line -*- tcl -*- \\\n> -exec wish \"$0\" -- \"$@\"\n> +exec wish8.5 \"$0\" -- \"$@\"\n> \n> # Copyright (C) 2005-2006 Paul Mackerras. All rights reserved.\n> # This program is free software; it may be used, copied, modified\n> -- \n> 1.5.3.5.1541.gd2b5c-dirty\n\n F*CK this chunk is obviously spurious.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58400","messageId":"20071105190556.GG22767@fieldses.org","threadId":"10672","inReplyTo":"20071105190411.GG6205@artemis.corp","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-05T19:05:56Z","receivedAt":"2007-11-05T19:05:56Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Nov 05, 2007 at 08:04:11PM +0100, Pierre Habouzit wrote:\n> On Mon, Nov 05, 2007 at 07:01:41PM +0000, Pierre Habouzit wrote:\n> > +\t\tif (!lstat(name, &st)) {\n> > +\t\t\tdie(\"Cannot find commit '%s', did you meant: \"\n\ns/meant/mean/\n\n> > +\t\t\t\t\"git checkout HEAD -- '%s'\", arg, arg);\n> > +\t\t} else {\n> > +\t\t\tdie(\"Cannot find commit '%s'\", arg);\n> > +\t\t}\n> > +\t}\n\n--b.\n"},{"id":"58401","messageId":"20071105191004.GH6205@artemis.corp","threadId":"10672","inReplyTo":"20071105190556.GG22767@fieldses.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-05T19:10:04Z","receivedAt":"2007-11-05T19:10:04Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 05, 2007 at 07:05:56PM +0000, J. Bruce Fields wrote:\n> On Mon, Nov 05, 2007 at 08:04:11PM +0100, Pierre Habouzit wrote:\n> > On Mon, Nov 05, 2007 at 07:01:41PM +0000, Pierre Habouzit wrote:\n> > > +\t\tif (!lstat(name, &st)) {\n> > > +\t\t\tdie(\"Cannot find commit '%s', did you meant: \"\n> \n> s/meant/mean/\n\nYeah I wrote that out of the iritation of the 192812948th question about\nthat on #git, I should have read my patch it seems :)\n\nThough, if there will be a new maint release, I do believe that this\npatch is maint material.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58404","messageId":"CD2E6759-9E7E-41E6-8B58-AB6CA9604111@midwinter.com","threadId":"10672","inReplyTo":"1194289301-7800-1-git-send-email-madcoder@debian.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-05T19:28:03Z","receivedAt":"2007-11-05T19:28:03Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 5, 2007, at 11:01 AM, Pierre Habouzit wrote:\n> When git-revert has a file argument then redirect the user to what he\n> probably meant.\n\nThat's a big improvement. Basically everyone I show git to gets \n\"revert\" wrong at first.\n\n> +\t\t\tdie(\"Cannot find commit '%s', did you meant: \"\n> +\t\t\t\t\"git checkout HEAD -- '%s'\", arg, arg);\n\nBut that suggested command is not going to convince anyone they were \nwrong about git being hard to learn. I wonder if instead of saying, \"I \nknow what you meant, but I'm going to make you type a different \ncommand,\" we should make git revert just do what the user meant.\n\nThere is already precedent for that kind of mixed-mode UI:\n\ngit checkout my-branch\nvs.\ngit checkout my/source/file.c\n\n-Steve\n"},{"id":"58407","messageId":"20071105195011.GB8939@artemis.corp","threadId":"10672","inReplyTo":"CD2E6759-9E7E-41E6-8B58-AB6CA9604111@midwinter.com","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-05T19:50:11Z","receivedAt":"2007-11-05T19:50:11Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 05, 2007 at 07:28:03PM +0000, Steven Grimm wrote:\n> On Nov 5, 2007, at 11:01 AM, Pierre Habouzit wrote:\n> >When git-revert has a file argument then redirect the user to what he\n> >probably meant.\n> \n> That's a big improvement. Basically everyone I show git to gets \"revert\" \n> wrong at first.\n> \n> >+\t\t\tdie(\"Cannot find commit '%s', did you meant: \"\n> >+\t\t\t\t\"git checkout HEAD -- '%s'\", arg, arg);\n> \n> But that suggested command is not going to convince anyone they were \n> wrong about git being hard to learn. I wonder if instead of saying, \"I \n> know what you meant, but I'm going to make you type a different command,\" \n> we should make git revert just do what the user meant.\n\n That's an option, but it wouldn't be maint material then :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58431","messageId":"20071105215433.GA12827@inspiron","threadId":"10672","inReplyTo":"CD2E6759-9E7E-41E6-8B58-AB6CA9604111@midwinter.com","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Alejandro Martinez Ruiz","fromEmail":"alex@flawedcode.org","sentAt":"2007-11-05T21:54:33Z","receivedAt":"2007-11-05T21:54:33Z","isPatch":true,"sender":{"key":"alex@flawedcode.org","avatar":"https://gravatar.com/avatar/aae35e2f84230bfbc19c9b840ef8437fcb110f5316ea91197e3cd96c4bb4bf30?d=mp&s=160"},"body":"On Mon 05 Nov 2007, 11:28, Steven Grimm wrote:\n>\n> But that suggested command is not going to convince anyone they were wrong \n> about git being hard to learn. I wonder if instead of saying, \"I know what \n> you meant, but I'm going to make you type a different command,\" we should \n> make git revert just do what the user meant.\n\nI think that would just add to confusion. \"revert\" applies to full\nchangesets, not single files, plus it creates a new commit, which is\nprobably not what the user wants. Most of them just want to revert some\nlocal changes to some random files, so teach them what they need, if\nanything.\n\n> There is already precedent for that kind of mixed-mode UI:\n>\n> git checkout my-branch\n> vs.\n> git checkout my/source/file.c\n\nThis is a different case: you're basically performing the same\noperation, with the second line applying just to a subset of files.\n\n- Alex\n"},{"id":"58432","messageId":"85sl3kny8u.fsf@lola.goethe.zz","threadId":"10672","inReplyTo":"20071105215433.GA12827@inspiron","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-05T22:06:25Z","receivedAt":"2007-11-05T22:06:25Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Alejandro Martinez Ruiz writes:\n\n> On Mon 05 Nov 2007, 11:28, Steven Grimm wrote:\n>>\n>> But that suggested command is not going to convince anyone they were wrong \n>> about git being hard to learn. I wonder if instead of saying, \"I know what \n>> you meant, but I'm going to make you type a different command,\" we should \n>> make git revert just do what the user meant.\n>\n> I think that would just add to confusion. \"revert\" applies to full\n> changesets, not single files, plus it creates a new commit, which is\n> probably not what the user wants. Most of them just want to revert some\n> local changes to some random files, so teach them what they need, if\n> anything.\n>\n>> There is already precedent for that kind of mixed-mode UI:\n>>\n>> git checkout my-branch\n>> vs.\n>> git checkout my/source/file.c\n>\n> This is a different case: you're basically performing the same\n> operation, with the second line applying just to a subset of files.\n\nHuh? The first one moves HEAD. The second one doesn't.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"58435","messageId":"7vlk9cmiyq.fsf@gitster.siamese.dyndns.org","threadId":"10672","inReplyTo":"CD2E6759-9E7E-41E6-8B58-AB6CA9604111@midwinter.com","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-05T22:21:49Z","receivedAt":"2007-11-05T22:21:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> But that suggested command is not going to convince anyone they were\n> wrong about git being hard to learn. I wonder if instead of saying, \"I\n> know what you meant, but I'm going to make you type a different\n> command,\" we should make git revert just do what the user meant.\n>\n> There is already precedent for that kind of mixed-mode UI:\n>\n> git checkout my-branch\n> vs.\n> git checkout my/source/file.c\n\nThat's an example of mixed-mode UI, but what you are suggesting\nis quite different, isn't it?\n\nThere is no other officially supported single-command-way to\ncheckout paths out of the index. \"git checkout paths...\" does\nnot introduce a confusion because of that. The user learns the\nway git supports that concept and that's the end of the story.\nThe same thing can be said about \"git checkout \npaths...\". That's _the_ way to checkout paths out of an\narbitrary commit.\n\nIn the case being discussed, we already have the concept of\nchecking out paths from the index, which has an officially\nsupported way to express.\n\nYou are proposing to give it a synonym \"git revert paths...\",\nwhich superfitially sounds friendlier. But I actually think\nallowing a mistaken\n\n\tgit revert path...\n\nto be burned to users' fingers and brains is doing the user a\ngreat disservice.\n\nThe next person would say \"Why doesn't 'git revert HEAD path...'\nwork?\", and you would add the synonym to do 'git checkout HEAD\npath...'. Up to that point it is sort-of Ok (but not quite).\nYou already have \"git checkout\" that let's you do so, but you\nintroduced new concepts that are \"revert paths to the index\" and\n\"revert paths to the last commit\".\n\nWhich may make you feel good, but you just introduced a narrower\nsynonym the user needs to learn, than a more established and\nwider concept that we already have: \"checkout paths out of X\",\nwhere X are either the index or an arbitrary commit.\n\nThe reason I think the narrower synonym is bad and will lead to\nmore user confusion is because after that point you will have\na few issues.\n\nAnother newcomer would say \"I like the fact that 'git revert\nHEAD path...' works but why doesn't 'git revert HEAD~12 path...'\nwork?\".\n\n - You may further allow \"git revert \n path...\". But what does that _mean_? \"revert the path to\n the twelfth commit\"? You may implement that _anyway_.\n\n Then, the user would say \"eh, why do you have both 'git\n checkout path...' and 'git revert path...' that seem to do\n the same thing? There's no difference? Why Why Why, git is\n so hard to learn\".\n\n - You may instead not to do so, and explain that the \"arbitrary\n commit\" form is not supported and tell the user to use \"git\n checkout paths...\".\n\n The user will say: \"but you earlier told me to use revert --\n you could have taught me to use checkout from the beginning\n and saved me from great confusion instead\".\n\nGiving the same concept two different names is bad unless there\nis a compelling reason to do so. Labelling an initially\nnarrower subset of an existing concept with a different name,\nand having to extended that 'new concept' ending up with the\nsame as the existing concept is even worse.\n"},{"id":"58452","messageId":"Pine.LNX.4.64.0711052325090.4362@racer.site","threadId":"10672","inReplyTo":"7vlk9cmiyq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-05T23:40:46Z","receivedAt":"2007-11-05T23:40:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Nov 2007, Junio C Hamano wrote:\n\n> Steven Grimm writes:\n> \n> > But that suggested command is not going to convince anyone they were\n> > wrong about git being hard to learn. I wonder if instead of saying, \"I\n> > know what you meant, but I'm going to make you type a different\n> > command,\" we should make git revert just do what the user meant.\n> >\n> > There is already precedent for that kind of mixed-mode UI:\n> >\n> > git checkout my-branch\n> > vs.\n> > git checkout my/source/file.c\n> \n> That's an example of mixed-mode UI, but what you are suggesting is quite \n> different, isn't it?\n> \n> There is no other officially supported single-command-way to\n> checkout paths out of the index.\n\nOkay, let's step back a bit.\n\nWe taught \"git show\" to show other objects than commits, by doing the \nobvious things. So there _is_ a precendent to changing a commands \nbehaviour to accept more than just commits. And there was already another \ncommand for the same purpose, cat-file, which was never meant as \nporcelain however.\n\nNow, what does \"revert\" _mean_? At the moment, it wants a commit, and \nwill undo the changes that commit introduced, _and commits it_ (asking \nfor a message).\n\nWhat would I expect \"git revert -- file\" to do? It would undo the changes \nto that file -- and since no commit was specified, I would expect it to \nlook at the changes against the index. (IOW exactly what Steven \nproposed.)\n\nTo continue the analogy, it would have to commit the undoing of the \nchange. But since that change never was committed, I think it is more \nnatural to _not_ commit it.\n\nIn the same way, I would expect \"git revert -- file\" to undo the \nchanges in that commit to _that_ file (something like \"git merge-file \nfile :file ^:file\"), but this time commit it, since it \nwas committed at one stage.\n\nIMHO this would be a consistent behaviour _and_ help new git users.\n\nAfter all, we are not Python, supposedly narrowing users down to \none-way-to-do-things only.\n\nCiao,\nDscho\n"},{"id":"58453","messageId":"20071105234147.GB12827@inspiron","threadId":"10672","inReplyTo":"85sl3kny8u.fsf@lola.goethe.zz","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Alejandro Martinez Ruiz","fromEmail":"alex@flawedcode.org","sentAt":"2007-11-05T23:41:47Z","receivedAt":"2007-11-05T23:41:47Z","isPatch":true,"sender":{"key":"alex@flawedcode.org","avatar":"https://gravatar.com/avatar/aae35e2f84230bfbc19c9b840ef8437fcb110f5316ea91197e3cd96c4bb4bf30?d=mp&s=160"},"body":"On Mon 05 Nov 2007, 23:06, David Kastrup wrote:\n> Alejandro Martinez Ruiz writes:\n> > On Mon 05 Nov 2007, 11:28, Steven Grimm wrote:\n> >\n> >> There is already precedent for that kind of mixed-mode UI:\n> >>\n> >> git checkout my-branch\n> >> vs.\n> >> git checkout my/source/file.c\n> >\n> > This is a different case: you're basically performing the same\n> > operation, with the second line applying just to a subset of files.\n> \n> Huh? The first one moves HEAD. The second one doesn't.\n\nThat's why I wrote \"basically\". Anyway, the point is that this doesn't\nseem to be a valid precedent.\n\n- Alex\n"},{"id":"58461","messageId":"20071106000839.GR8939@artemis.corp","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711052325090.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T00:08:39Z","receivedAt":"2007-11-06T00:08:39Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 05, 2007 at 11:40:46PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> \n> > Steven Grimm writes:\n> > \n> > > But that suggested command is not going to convince anyone they were\n> > > wrong about git being hard to learn. I wonder if instead of saying, \"I\n> > > know what you meant, but I'm going to make you type a different\n> > > command,\" we should make git revert just do what the user meant.\n> > >\n> > > There is already precedent for that kind of mixed-mode UI:\n> > >\n> > > git checkout my-branch\n> > > vs.\n> > > git checkout my/source/file.c\n> > \n> > That's an example of mixed-mode UI, but what you are suggesting is quite \n> > different, isn't it?\n> > \n> > There is no other officially supported single-command-way to\n> > checkout paths out of the index.\n> \n> Okay, let's step back a bit.\n> \n> We taught \"git show\" to show other objects than commits, by doing the \n> obvious things. So there _is_ a precendent to changing a commands \n> behaviour to accept more than just commits. And there was already another \n> command for the same purpose, cat-file, which was never meant as \n> porcelain however.\n> \n> Now, what does \"revert\" _mean_? At the moment, it wants a commit, and \n> will undo the changes that commit introduced, _and commits it_ (asking \n> for a message).\n> \n> What would I expect \"git revert -- file\" to do? It would undo the changes \n> to that file -- and since no commit was specified, I would expect it to \n> look at the changes against the index. (IOW exactly what Steven \n> proposed.)\n> \n> To continue the analogy, it would have to commit the undoing of the \n> change. But since that change never was committed, I think it is more \n> natural to _not_ commit it.\n> \n> In the same way, I would expect \"git revert -- file\" to undo the \n> changes in that commit to _that_ file (something like \"git merge-file \n> file :file ^:file\"), but this time commit it, since it \n> was committed at one stage.\n\n I agree that this is something that really makes sense to me, and does\nnot looks like a perversion of the UI, and quite a nice extension in\nfact. And it would _finally_ solve the issue that for _ANYTHING_ on the\nplanet that I've used for more than 10 seconds, $SCM revert path/to/file\nreverts local changes :)\n\n When you look at how git-revert is implemented, you'll see that it\nuses the very same code as git cherry-pick does, and in fact, I've\nwanted a git cherry-pick -- path1 path2 path3 for a _very_ long\ntime, and your proposal would just gracefully give it as a bonus I\nbelieve (of course uncommited changes have no sense for a cherry-pick).\n\n I like it a lot.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58479","messageId":"7vsl3kjdct.fsf@gitster.siamese.dyndns.org","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711052325090.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-06T02:51:14Z","receivedAt":"2007-11-06T02:51:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> In the same way, I would expect \"git revert -- file\" to undo the \n> changes in that commit to _that_ file (something like \"git merge-file \n> file :file ^:file\"), but this time commit it, since it \n> was committed at one stage.\n\nAllowing people to revert or cherry pick partially by using\npaths limiter is a very good idea; the whole \"it comes from a\ncommit so we also commit\" feels an utter nonsense, though.\n"},{"id":"58481","messageId":"Pine.LNX.4.64.0711060317220.4362@racer.site","threadId":"10672","inReplyTo":"7vsl3kjdct.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T03:18:34Z","receivedAt":"2007-11-06T03:18:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > In the same way, I would expect \"git revert -- file\" to undo \n> > the changes in that commit to _that_ file (something like \"git \n> > merge-file file :file ^:file\"), but this time commit \n> > it, since it was committed at one stage.\n> \n> Allowing people to revert or cherry pick partially by using paths \n> limiter is a very good idea; the whole \"it comes from a commit so we \n> also commit\" feels an utter nonsense, though.\n\nNo.\n\nWhen \"git revert \" commits the result, \"git revert -- \n\" should, too.\n\nYou can always add the \"-n\" option.\n\nCiao,\nDscho\n"},{"id":"58488","messageId":"7vode8j7o5.fsf@gitster.siamese.dyndns.org","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711060317220.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-06T04:54:02Z","receivedAt":"2007-11-06T04:54:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 5 Nov 2007, Junio C Hamano wrote:\n>\n>> Allowing people to revert or cherry pick partially by using paths \n>> limiter is a very good idea; the whole \"it comes from a commit so we \n>> also commit\" feels an utter nonsense, though.\n>\n> No.\n>\n> When \"git revert \" commits the result, \"git revert -- \n> \" should, too.\n\nI was not questioning about that part. \"If 'git revert foo' does not talk about commit, it should not\ncommit\" was what I was referring to.\n"},{"id":"58508","messageId":"20071106084925.GC4435@artemis.corp","threadId":"10672","inReplyTo":"7vode8j7o5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T08:49:25Z","receivedAt":"2007-11-06T08:49:25Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> >\n> >> Allowing people to revert or cherry pick partially by using paths \n> >> limiter is a very good idea; the whole \"it comes from a commit so we \n> >> also commit\" feels an utter nonsense, though.\n> >\n> > No.\n> >\n> > When \"git revert \" commits the result, \"git revert -- \n> > \" should, too.\n> \n> I was not questioning about that part. \"If 'git revert other form> foo' does not talk about commit, it should not\n> commit\" was what I was referring to.\n\n Well, I don't really know how closely you read #git, but I'd say that\n\"how do I undo my local changes in a git repository\" is among the top 3\nquestions. There _IS_ an UI issue for that.\n\nIf git revert -- path1 path2 path3 is going to work at some\npoint, I see no harm in saying that git revert HEAD -- path1 path2 path3\nwork. We can also in that case spit an error message:\n\nerror: this works as a courtesy but you really meant git checkout -- path/to/file\n\n On some other issues I'm all about educating people and learning to\nthem how to \"think different\". But here it's a pure interface problem,\nand git is the sole $scm with a revert commands that doesn't reverts\nlocal changes wrt HEAD.\n\n The next release of master will have tons of UI improvements (terse\noutput, better options parsing, more builtins hence faster commands …),\nI believe it's stopping halfway not thinking about issues like this from\na newcomer point of view.\n\n On the pure theoretical basis I believe you're right, it's a bit\nmixing apples and oranges. On the pragmatic usability side I'm quite\nsure you're wrong, because everyone is used to that:\n\n $ hg revert --help | head -3 | tail -1\n revert files or dirs to their states as of some revision\n\n $ bzr help revert | head -1\n Purpose: Revert files to a previous revision.\n\n $ svn help revert | head -1\n revert: Restore pristine working copy file (undo most local edits).\n\n $ darcs help revert | head -3 | tail -1\n Revert to the recorded version (safe the first time only).\n\n \n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58515","messageId":"20071106092942.GB3197@glandium.org","threadId":"10672","inReplyTo":"20071106084925.GC4435@artemis.corp","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-06T09:29:42Z","receivedAt":"2007-11-06T09:29:42Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit wrote:\n> On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:\n> > Johannes Schindelin writes:\n> > \n> > > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> > >\n> > >> Allowing people to revert or cherry pick partially by using paths \n> > >> limiter is a very good idea; the whole \"it comes from a commit so we \n> > >> also commit\" feels an utter nonsense, though.\n> > >\n> > > No.\n> > >\n> > > When \"git revert \" commits the result, \"git revert -- \n> > > \" should, too.\n> > \n> > I was not questioning about that part. \"If 'git revert > other form> foo' does not talk about commit, it should not\n> > commit\" was what I was referring to.\n> \n> Well, I don't really know how closely you read #git, but I'd say that\n> \"how do I undo my local changes in a git repository\" is among the top 3\n> questions. There _IS_ an UI issue for that.\n> \n> If git revert -- path1 path2 path3 is going to work at some\n> point, I see no harm in saying that git revert HEAD -- path1 path2 path3\n> work. We can also in that case spit an error message:\n\nIt seems to me git revert HEAD -- path1 path2 path3 should revert the changes\nmade in the commit pointed to by HEAD, not revert the changes in the working\ntree or the index...\n\nMike\n"},{"id":"58516","messageId":"20071106093756.GH4435@artemis.corp","threadId":"10672","inReplyTo":"20071106092942.GB3197@glandium.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T09:37:56Z","receivedAt":"2007-11-06T09:37:56Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 09:29:42AM +0000, Mike Hommey wrote:\n> On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit wrote:\n> > On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:\n> > > Johannes Schindelin writes:\n> > > \n> > > > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> > > >\n> > > >> Allowing people to revert or cherry pick partially by using paths \n> > > >> limiter is a very good idea; the whole \"it comes from a commit so we \n> > > >> also commit\" feels an utter nonsense, though.\n> > > >\n> > > > No.\n> > > >\n> > > > When \"git revert \" commits the result, \"git revert -- \n> > > > \" should, too.\n> > > \n> > > I was not questioning about that part. \"If 'git revert > > other form> foo' does not talk about commit, it should not\n> > > commit\" was what I was referring to.\n> > \n> > Well, I don't really know how closely you read #git, but I'd say that\n> > \"how do I undo my local changes in a git repository\" is among the top 3\n> > questions. There _IS_ an UI issue for that.\n> > \n> > If git revert -- path1 path2 path3 is going to work at some\n> > point, I see no harm in saying that git revert HEAD -- path1 path2 path3\n> > work. We can also in that case spit an error message:\n> \n> It seems to me git revert HEAD -- path1 path2 path3 should revert the changes\n> made in the commit pointed to by HEAD, not revert the changes in the working\n> tree or the index...\n\n Yes, sorry, the `HEAD` in my sentence was spurious.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58524","messageId":"7vk5oviqbe.fsf@gitster.siamese.dyndns.org","threadId":"10672","inReplyTo":"7vsl3kjdct.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-06T11:08:53Z","receivedAt":"2007-11-06T11:08:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Schindelin writes:\n>\n>> In the same way, I would expect \"git revert -- file\" to undo the \n>> changes in that commit to _that_ file (something like \"git merge-file \n>> file :file ^:file\"), but this time commit it, since it \n>> was committed at one stage.\n>\n> Allowing people to revert or cherry pick partially by using\n> paths limiter is a very good idea; ...\n\nAs Pierre said earlier, a partial revert via \"revert --\n\" and a partial cherry-pick would make quite a lot of\nsense, and in addition, it should not be too hard to add.\n\nReusing the 'merge-recursive' part should be almost trivial.\nThe only tricky part is coming up with a fake tree using base\nand next commit in revert_or_cherry_pick() for this purpose.\n\nWhen replaying the change from A->B (when cherry-picking, A is\nthe parent and B is what was named from the command line; when\nreverting, they are the other way around), instead of doing the\nthree-way merge using:\n\n\tmerge-recursive A HEAD B\n\nyou would first come up with a modified tree B' that has the\nidentical contents to A _except_ the parts the path limiters\nspecify which are taken from B. Then running\n\n\tmerge-recursive A HEAD B'\n\nwould replay the revert or cherry-pick of change from A->B,\nlimited by the path, on top of the current HEAD.\n\nAs to \"reverting to the index\" case, if somebody is interested\nin doing a builtin-checkout.c, please keep in mind that major\nparts of that work should be made available to the\nimplementation of \"git revert [--] \", as it appears that\nit will be exactly the same as \"git checkout\" with the same set\nof options.\n\nI am wondering what \"git cherry-pick -- \" should do. My\ncurrent thinking is that it would not make any sense at all.\n"},{"id":"58526","messageId":"47305536.5010308@viscovery.net","threadId":"10672","inReplyTo":"7vk5oviqbe.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-11-06T11:51:18Z","receivedAt":"2007-11-06T11:51:18Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> I am wondering what \"git cherry-pick -- \" should do. My\n> current thinking is that it would not make any sense at all.\n\nIMO, at least \"git cherry-pick -n -- \" makes tons of sense.\n\n-- Hannes\n"},{"id":"58531","messageId":"Pine.LNX.4.64.0711061214520.4362@racer.site","threadId":"10672","inReplyTo":"47305536.5010308@viscovery.net","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T12:16:21Z","receivedAt":"2007-11-06T12:16:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Johannes Sixt wrote:\n\n> Junio C Hamano schrieb:\n> > I am wondering what \"git cherry-pick -- \" should do. My\n> > current thinking is that it would not make any sense at all.\n> \n> IMO, at least \"git cherry-pick -n -- \" makes tons of sense.\n\nI guess you missed that Junio did not specify any commit. With a commit, \nI agree, it makes tons of sense.\n\nWithout a commit, it would default to... uhm... HEAD? And applying the \nchanges to a given file, which are already in HEAD, no, that does not make \nsense.\n\nCiao,\nDscho\n"},{"id":"58532","messageId":"Pine.LNX.4.64.0711061216330.4362@racer.site","threadId":"10672","inReplyTo":"7vk5oviqbe.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T12:25:33Z","receivedAt":"2007-11-06T12:25:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > Johannes Schindelin writes:\n> >\n> >> In the same way, I would expect \"git revert -- file\" to undo the \n> >> changes in that commit to _that_ file (something like \"git merge-file \n> >> file :file ^:file\"), but this time commit it, since it \n> >> was committed at one stage.\n> >\n> > Allowing people to revert or cherry pick partially by using\n> > paths limiter is a very good idea; ...\n> \n> As Pierre said earlier, a partial revert via \"revert --\n> \" and a partial cherry-pick would make quite a lot of\n> sense, and in addition, it should not be too hard to add.\n\nYes, but Pierre also said earlier that people want to revert their local \nchanges. And the logical thing to try that really is\n\n\tgit revert \n\nNow, if you read that out in English, it does not make too much sense: \n\"revert the path\" (not \"revert the _changes_ to that file\"). But it is \nwhat people try to do.\n\nHowever, IIUC another thing Pierre mentioned is that\n\n\t$scm revert \n\ncommonly means \"revert the file _to the version_ stored in \". \nThis is just different enough from \"revert the _changes_ to that file \nstored in \" to bite people, no?\n\n> Reusing the 'merge-recursive' part should be almost trivial. The only \n> tricky part is coming up with a fake tree using base and next commit in \n> revert_or_cherry_pick() for this purpose.\n\nFWIW I really wanted to use the merge-file machinery, not the \nmerge-recursive one. But since \"\" can be a directory, too, I was \nmistaken, and you are correct, as always.\n\n> As to \"reverting to the index\" case, if somebody is interested in doing \n> a builtin-checkout.c, please keep in mind that major parts of that work \n> should be made available to the implementation of \"git revert [--] \n> \", as it appears that it will be exactly the same as \"git \n> checkout\" with the same set of options.\n\nI was planning to put cmd_checkout() into builtin-reset.c for that reason.\n\nBut first things first, that \"git remote prune\" with --mirror'ed \nrepositories misbehaviour annoys me just enough that I started converting \nthis script first. It has been stable enough for quite a long time, and \nthe script now shows its limitations.\n\nBesides, remote.[ch] makes it easy, even if not _really_ easy.\n\nCiao,\nDscho\n"},{"id":"58533","messageId":"Pine.LNX.4.64.0711061230540.4362@racer.site","threadId":"10672","inReplyTo":"7vode8j7o5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T12:32:24Z","receivedAt":"2007-11-06T12:32:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> >\n> >> Allowing people to revert or cherry pick partially by using paths \n> >> limiter is a very good idea; the whole \"it comes from a commit so we \n> >> also commit\" feels an utter nonsense, though.\n> >\n> > No.\n> >\n> > When \"git revert \" commits the result, \"git revert -- \n> > \" should, too.\n> \n> I was not questioning about that part. \"If 'git revert other form> foo' does not talk about commit, it should not\n> commit\" was what I was referring to.\n\nWell, I think that _if_ we allow \"git revert \" to mean \"revert the \nchanges to , relative to the index\" (which would be the same as \"git \ncheckout \"), then committing that change just does not make sense.\n\nAnd it is this behaviour that people are seeking, not \"git revert \n\".\n\nCiao,\nDscho\n"},{"id":"58535","messageId":"20071106124833.GA25637@artemis.corp","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711061216330.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T12:48:33Z","receivedAt":"2007-11-06T12:48:33Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:\n> Hi,\n>\n> On Tue, 6 Nov 2007, Junio C Hamano wrote:\n>\n> > Junio C Hamano writes:\n> >\n> > > Johannes Schindelin writes:\n> > >\n> > >> In the same way, I would expect \"git revert -- file\" to undo the\n> > >> changes in that commit to _that_ file (something like \"git merge-file\n> > >> file :file ^:file\"), but this time commit it, since it\n> > >> was committed at one stage.\n> > >\n> > > Allowing people to revert or cherry pick partially by using\n> > > paths limiter is a very good idea; ...\n> >\n> > As Pierre said earlier, a partial revert via \"revert --\n> > \" and a partial cherry-pick would make quite a lot of\n> > sense, and in addition, it should not be too hard to add.\n>\n> Yes, but Pierre also said earlier that people want to revert their local\n> changes. And the logical thing to try that really is\n>\n> \tgit revert \n>\n> Now, if you read that out in English, it does not make too much sense:\n> \"revert the path\" (not \"revert the _changes_ to that file\"). But it is\n> what people try to do.\n>\n> However, IIUC another thing Pierre mentioned is that\n>\n> \t$scm revert \n>\n> commonly means \"revert the file _to the version_ stored in \".\n> This is just different enough from \"revert the _changes_ to that file\n> stored in \" to bite people, no?\n\n Yeah but that's what checkout is for. The main source of iritation for\nnew users comes (IMHO) from svn, where `svn revert path/to/file` is part\nof the workflow: in case of a conflict when you `svn up`, you have\neither to:\n (1) fix the conflict and `svn resolved path/to/file`\n (2) drop your changes and take the trunk version `svn revert path/to/file`\n\nPeople really expect git revert -- path/to/file to do the same as git\ncheckout HEAD -- path/to/file. Though I believe that like I said, maybe\nwe don't wan't git revert -- path/to/file to become the first class\ncommand to do that, but rather to do what the user meant, hinting him in\nthe direction of the proper command. I wasn't really advocating that\ngit-revert should be a complete implementation of what git checkout\n -- does. YMMV.\n\n--\n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58554","messageId":"7790B5EB-2EFC-47EF-8A5A-FA83CA26DDB9@wincent.com","threadId":"10672","inReplyTo":"20071106124833.GA25637@artemis.corp","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-06T17:43:39Z","receivedAt":"2007-11-06T17:43:39Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 6/11/2007, a las 13:48, Pierre Habouzit escribió:\n\n> On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:\n>> Hi,\n>>\n>> On Tue, 6 Nov 2007, Junio C Hamano wrote:\n>>\n>>> Junio C Hamano writes:\n>>>\n>>>> Johannes Schindelin writes:\n>>>>\n>>>>> In the same way, I would expect \"git revert -- file\" to \n>>>>> undo the\n>>>>> changes in that commit to _that_ file (something like \"git merge- \n>>>>> file\n>>>>> file :file ^:file\"), but this time commit it, \n>>>>> since it\n>>>>> was committed at one stage.\n>>>>\n>>>> Allowing people to revert or cherry pick partially by using\n>>>> paths limiter is a very good idea; ...\n>>>\n>>> As Pierre said earlier, a partial revert via \"revert --\n>>> \" and a partial cherry-pick would make quite a lot of\n>>> sense, and in addition, it should not be too hard to add.\n>>\n>> Yes, but Pierre also said earlier that people want to revert their \n>> local\n>> changes. And the logical thing to try that really is\n>>\n>> \tgit revert \n>>\n>> Now, if you read that out in English, it does not make too much \n>> sense:\n>> \"revert the path\" (not \"revert the _changes_ to that file\"). But \n>> it is\n>> what people try to do.\n>>\n>> However, IIUC another thing Pierre mentioned is that\n>>\n>> \t$scm revert \n>>\n>> commonly means \"revert the file _to the version_ stored in \".\n>> This is just different enough from \"revert the _changes_ to that file\n>> stored in \" to bite people, no?\n>\n> Yeah but that's what checkout is for. The main source of iritation \n> for\n> new users comes (IMHO) from svn, where `svn revert path/to/file` is \n> part\n> of the workflow: in case of a conflict when you `svn up`, you have\n> either to:\n> (1) fix the conflict and `svn resolved path/to/file`\n> (2) drop your changes and take the trunk version `svn revert path/ \n> to/file`\n>\n> People really expect git revert -- path/to/file to do the same as git\n> checkout HEAD -- path/to/file. Though I believe that like I said, \n> maybe\n> we don't wan't git revert -- path/to/file to become the first class\n> command to do that, but rather to do what the user meant, hinting \n> him in\n> the direction of the proper command. I wasn't really advocating that\n> git-revert should be a complete implementation of what git checkout\n> -- does. YMMV.\n\n\nI agree; they're semantically different and it wouldn't be a good \nthing to start blurring the lines between them too much. It's just \nunfortunate that the term \"revert\" is used by most other SCMs to mean \nsomething different than what it means in \"git-revert\". I think the \nbest path here is education, what Pierre says, rather than changing \ngit-revert's semantics.\n\nThe other changes discussed so far in this thread (path-limiting git- \nrevert with preserving its semantics) seem like a good thing.\n\nCheers,\nWincent\n"},{"id":"58557","messageId":"7v8x5bi703.fsf@gitster.siamese.dyndns.org","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711061230540.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-06T18:06:04Z","receivedAt":"2007-11-06T18:06:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Well, I think that _if_ we allow \"git revert \" to mean \"revert the \n> changes to , relative to the index\" (which would be the same as \"git \n> checkout \"), then committing that change just does not make sense.\n>\n> And it is this behaviour that people are seeking, not \"git revert \n> \".\n\nHeh, I found this in the recent log somewhere.\n\n Really, I wonder how difficult git is for people who are not\n\tbrainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.\n From a user perspective, you might be correct. But then we have to\n\tadd 1000 commands to reflect the English language.\n Not what I want.\t\t\t\t\t\t[06:46]\n\nI am wondering who said it ;-).\n\nBut anyway, I am inclined to agree that accepting \"$scm revert\npaths..\" as a synonym for \"git checkout -- paths...\"\n"},{"id":"58562","messageId":"Pine.LNX.4.64.0711061827030.4362@racer.site","threadId":"10672","inReplyTo":"7v8x5bi703.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T18:27:54Z","receivedAt":"2007-11-06T18:27:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Well, I think that _if_ we allow \"git revert \" to mean \"revert the \n> > changes to , relative to the index\" (which would be the same as \"git \n> > checkout \"), then committing that change just does not make sense.\n> >\n> > And it is this behaviour that people are seeking, not \"git revert \n> > \".\n> \n> Heh, I found this in the recent log somewhere.\n> \n> Really, I wonder how difficult git is for people who are not\n> \tbrainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.\n> From a user perspective, you might be correct. But then we have to\n> \tadd 1000 commands to reflect the English language.\n> Not what I want.\t\t\t\t\t\t[06:46]\n> \n> I am wondering who said it ;-).\n\nNow, that is not fair, using my own words against me ;-)\n\nCiao,\nDscho\n"},{"id":"58571","messageId":"20071106193959.GB4382@artemis.corp","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711061827030.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-06T19:39:59Z","receivedAt":"2007-11-06T19:39:59Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 6 Nov 2007, Junio C Hamano wrote:\n> \n> > Johannes Schindelin writes:\n> > \n> > > Well, I think that _if_ we allow \"git revert \" to mean \"revert the \n> > > changes to , relative to the index\" (which would be the same as \"git \n> > > checkout \"), then committing that change just does not make sense.\n> > >\n> > > And it is this behaviour that people are seeking, not \"git revert \n> > > \".\n> > \n> > Heh, I found this in the recent log somewhere.\n> > \n> > Really, I wonder how difficult git is for people who are not\n> > \tbrainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.\n> > From a user perspective, you might be correct. But then we have to\n> > \tadd 1000 commands to reflect the English language.\n> > Not what I want.\t\t\t\t\t\t[06:46]\n> > \n> > I am wondering who said it ;-).\n> \n> Now, that is not fair, using my own words against me ;-)\n\n That's very funny actually :]\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58572","messageId":"7vir4fgnz1.fsf@gitster.siamese.dyndns.org","threadId":"10672","inReplyTo":"20071106193959.GB4382@artemis.corp","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-06T19:42:26Z","receivedAt":"2007-11-06T19:42:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:\n>> Hi,\n>> \n>> On Tue, 6 Nov 2007, Junio C Hamano wrote:\n>> \n>> > Johannes Schindelin writes:\n>> > \n>> > > Well, I think that _if_ we allow \"git revert \" to mean \"revert the \n>> > > changes to , relative to the index\" (which would be the same as \"git \n>> > > checkout \"), then committing that change just does not make sense.\n>> > >\n>> > > And it is this behaviour that people are seeking, not \"git revert \n>> > > \".\n>> > \n>> > Heh, I found this in the recent log somewhere.\n>> > \n>> > Really, I wonder how difficult git is for people who are not\n>> > \tbrainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.\n>> > From a user perspective, you might be correct. But then we have to\n>> > \tadd 1000 commands to reflect the English language.\n>> > Not what I want.\t\t\t\t\t\t[06:46]\n>> > \n>> > I am wondering who said it ;-).\n>> \n>> Now, that is not fair, using my own words against me ;-)\n>\n> That's very funny actually :]\n\nYeah, it was doubly funny after I saw you posted a list of \"$scm revert\"\nand Dscho still sided with you in that thread.\n"},{"id":"58574","messageId":"200711062106.57083.robin.rosenberg.lists@dewire.com","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711061230540.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-11-06T20:06:56Z","receivedAt":"2007-11-06T20:06:56Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 06 november 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> \n> > Johannes Schindelin writes:\n> > \n> > > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> > >\n> > >> Allowing people to revert or cherry pick partially by using paths \n> > >> limiter is a very good idea; the whole \"it comes from a commit so we \n> > >> also commit\" feels an utter nonsense, though.\n> > >\n> > > No.\n> > >\n> > > When \"git revert \" commits the result, \"git revert -- \n> > > \" should, too.\n> > \n> > I was not questioning about that part. \"If 'git revert > other form> foo' does not talk about commit, it should not\n> > commit\" was what I was referring to.\n> \n> Well, I think that _if_ we allow \"git revert \" to mean \"revert the \n> changes to , relative to the index\" (which would be the same as \"git \n> checkout \"), then committing that change just does not make sense.\n> \n> And it is this behaviour that people are seeking, not \"git revert \n> \".\n\nI'm not convince making every command perform enitrely all kinds of actions \njust because other SCMs interpret a name differently. git revert today \ncreates a *new* commit. Keep it simple. I think its ok that it mentions \nanother comnand when it detects arguments that does not make sense. There is \nno right or wrong with interepreting reset either way, but not both ways \nplease. The confusion with checkout and reset is enough.\n\n-- robin\n"},{"id":"58578","messageId":"20071106201324.GA30262@glandium.org","threadId":"10672","inReplyTo":"200711062106.57083.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-06T20:13:24Z","receivedAt":"2007-11-06T20:13:24Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 06, 2007 at 09:06:56PM +0100, Robin Rosenberg wrote:\n> tisdag 06 november 2007 skrev Johannes Schindelin:\n> > Hi,\n> > \n> > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> > \n> > > Johannes Schindelin writes:\n> > > \n> > > > On Mon, 5 Nov 2007, Junio C Hamano wrote:\n> > > >\n> > > >> Allowing people to revert or cherry pick partially by using paths \n> > > >> limiter is a very good idea; the whole \"it comes from a commit so we \n> > > >> also commit\" feels an utter nonsense, though.\n> > > >\n> > > > No.\n> > > >\n> > > > When \"git revert \" commits the result, \"git revert -- \n> > > > \" should, too.\n> > > \n> > > I was not questioning about that part. \"If 'git revert > > other form> foo' does not talk about commit, it should not\n> > > commit\" was what I was referring to.\n> > \n> > Well, I think that _if_ we allow \"git revert \" to mean \"revert the \n> > changes to , relative to the index\" (which would be the same as \"git \n> > checkout \"), then committing that change just does not make sense.\n> > \n> > And it is this behaviour that people are seeking, not \"git revert \n> > \".\n> \n> I'm not convince making every command perform enitrely all kinds of actions \n> just because other SCMs interpret a name differently. git revert today \n> creates a *new* commit. Keep it simple. I think its ok that it mentions \n> another comnand when it detects arguments that does not make sense. There is \n> no right or wrong with interepreting reset either way, but not both ways \n> please. The confusion with checkout and reset is enough.\n\nMaybe the documentation could emphasise on how to undo things when the\nuser makes mistakes.\nSometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.\nThis is not, unfortunately, a works-for-all-cases command.\n\nMike\n"},{"id":"58594","messageId":"200711062221.58475.robin.rosenberg.lists@dewire.com","threadId":"10672","inReplyTo":"20071106201324.GA30262@glandium.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-11-06T21:21:56Z","receivedAt":"2007-11-06T21:21:56Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 06 november 2007 skrev Mike Hommey:\n> Maybe the documentation could emphasise on how to undo things when the\n> user makes mistakes.\n> Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.\n> This is not, unfortunately, a works-for-all-cases command.\n\nYea, git-undo(7). \n\n-- robin\n"},{"id":"58602","messageId":"Pine.LNX.4.64.0711062220050.4362@racer.site","threadId":"10672","inReplyTo":"7vir4fgnz1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T22:21:18Z","receivedAt":"2007-11-06T22:21:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Junio C Hamano wrote:\n\n> Pierre Habouzit writes:\n> \n> > On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:\n> > \n> >> On Tue, 6 Nov 2007, Junio C Hamano wrote:\n> >> \n> >> > Johannes Schindelin writes:\n> >> > \n> >> > > Well, I think that _if_ we allow \"git revert \" to mean \n> >> > > \"revert the changes to , relative to the index\" (which \n> >> > > would be the same as \"git checkout \"), then committing that \n> >> > > change just does not make sense.\n> >> > >\n> >> > > And it is this behaviour that people are seeking, not \"git revert \n> >> > > \".\n> >> > \n> >> > Heh, I found this in the recent log somewhere.\n> >> > \n> >> > Really, I wonder how difficult git is for people who are not\n> >> > \tbrainwashed by cvs/svn, and unfortunately enough, partly by bzr \n> >> > and hg.\n> >> > From a user perspective, you might be correct. But then we \n> >> > have to add 1000 commands to reflect the English language.\n> >> > Not what I want.\t\t\t\t\t\t[06:46]\n> >> > \n> >> > I am wondering who said it ;-).\n> >> \n> >> Now, that is not fair, using my own words against me ;-)\n> >\n> > That's very funny actually :]\n> \n> Yeah, it was doubly funny after I saw you posted a list of \"$scm revert\" \n> and Dscho still sided with you in that thread.\n\nHey, I had my nice 5 minutes for the day, so give me a break!\n\n;-)\n\nCiao,\nDscho\n"},{"id":"58603","messageId":"Pine.LNX.4.64.0711062225090.4362@racer.site","threadId":"10672","inReplyTo":"200711062221.58475.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-06T22:25:48Z","receivedAt":"2007-11-06T22:25:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Nov 2007, Robin Rosenberg wrote:\n\n> tisdag 06 november 2007 skrev Mike Hommey:\n> > Maybe the documentation could emphasise on how to undo things when the\n> > user makes mistakes.\n> > Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.\n> > This is not, unfortunately, a works-for-all-cases command.\n> \n> Yea, git-undo(7). \n\nIn related news, I know a few users who need an un-rm-rf. Anyone?\n\nCiao,\nDscho\n"},{"id":"58650","messageId":"20071107081608.GA19066@glandium.org","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711062225090.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-07T08:16:08Z","receivedAt":"2007-11-07T08:16:08Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Nov 06, 2007 at 10:25:48PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 6 Nov 2007, Robin Rosenberg wrote:\n> \n> > tisdag 06 november 2007 skrev Mike Hommey:\n> > > Maybe the documentation could emphasise on how to undo things when the\n> > > user makes mistakes.\n> > > Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.\n> > > This is not, unfortunately, a works-for-all-cases command.\n> > \n> > Yea, git-undo(7). \n> \n> In related news, I know a few users who need an un-rm-rf. Anyone?\n\nThe fact is you can do harm to your repo with things you wouldn't expect to\nbreak things, except maybe you gave bad arguments or so. It's quite easy to\nfuck up with git-rebase, or to merge the wrong commits, etc.\n\nMike\n"},{"id":"58655","messageId":"868x5afmvr.fsf@lola.quinscape.zz","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711062225090.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-07T09:03:36Z","receivedAt":"2007-11-07T09:03:36Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 6 Nov 2007, Robin Rosenberg wrote:\n>\n>> tisdag 06 november 2007 skrev Mike Hommey:\n>> > Maybe the documentation could emphasise on how to undo things when the\n>> > user makes mistakes.\n>> > Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.\n>> > This is not, unfortunately, a works-for-all-cases command.\n>> \n>> Yea, git-undo(7). \n>\n> In related news, I know a few users who need an un-rm-rf. Anyone?\n\nMost file systems don't have a reflog or other ways to recover from\nshooting yourself in the foot. git has, and for good reason.\n\nThere is no sense in hiding that facility away because of feeling\nmacho. Since git already keeps the file space around needed for\nrecovery (and you really have to exert yourself to make it let go for\ngood), there is no point in not making it as convenient as feasible to\nrecover.\n\n-- \nDavid Kastrup\n"},{"id":"58668","messageId":"Pine.LNX.4.64.0711071103450.4362@racer.site","threadId":"10672","inReplyTo":"20071107081608.GA19066@glandium.org","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-07T11:08:04Z","receivedAt":"2007-11-07T11:08:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 7 Nov 2007, Mike Hommey wrote:\n\n> On Tue, Nov 06, 2007 at 10:25:48PM +0000, Johannes Schindelin wrote:\n> \n> > On Tue, 6 Nov 2007, Robin Rosenberg wrote:\n> > \n> > > tisdag 06 november 2007 skrev Mike Hommey:\n> > > > Maybe the documentation could emphasise on how to undo things when \n> > > > the user makes mistakes. Sometimes, saving your repo can be as \n> > > > simple as git reset --hard HEAD@{1}. This is not, unfortunately, a \n> > > > works-for-all-cases command.\n> > > \n> > > Yea, git-undo(7). \n> > \n> > In related news, I know a few users who need an un-rm-rf. Anyone?\n> \n> The fact is you can do harm to your repo with things you wouldn't expect \n> to break things, except maybe you gave bad arguments or so. It's quite \n> easy to fuck up with git-rebase, or to merge the wrong commits, etc.\n\nI don't see how these commands are dangerous. Usually you just look into \nthe reflog, pick the one commit you started with, and reset --hard.\n\nThe _only_ commands I find dangerous are \"git stash clear\" and \"git reflog \n--expire=0\". Funnily, people want to do that all the time.\n\nLike recently, on the IRC channel, where somebody lost patches \"during a \nrebase\", by \"rm -rf .dotest\".\n\nThere will be a point where nobody can help. But before that, reflogs are \nyour friend. But you must not do \"reset --hard HEAD@{1}\" blindly. You \nhave to look first what the reflogs are.\n\nCiao,\nDscho\n"},{"id":"58712","messageId":"200711072032.48193.robin.rosenberg.lists@dewire.com","threadId":"10672","inReplyTo":"Pine.LNX.4.64.0711071103450.4362@racer.site","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-11-07T19:32:47Z","receivedAt":"2007-11-07T19:32:47Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 07 november 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Wed, 7 Nov 2007, Mike Hommey wrote:\n> \n> > On Tue, Nov 06, 2007 at 10:25:48PM +0000, Johannes Schindelin wrote:\n> > \n> > > On Tue, 6 Nov 2007, Robin Rosenberg wrote:\n> > > \n> > > > tisdag 06 november 2007 skrev Mike Hommey:\n> > > > > Maybe the documentation could emphasise on how to undo things when \n> > > > > the user makes mistakes. Sometimes, saving your repo can be as \n> > > > > simple as git reset --hard HEAD@{1}. This is not, unfortunately, a \n> > > > > works-for-all-cases command.\n> > > > \n> > > > Yea, git-undo(7). \n> > > \n> > > In related news, I know a few users who need an un-rm-rf. Anyone?\n> > \n> > The fact is you can do harm to your repo with things you wouldn't expect \n> > to break things, except maybe you gave bad arguments or so. It's quite \n> > easy to fuck up with git-rebase, or to merge the wrong commits, etc.\n> \n> I don't see how these commands are dangerous. Usually you just look into \n> the reflog, pick the one commit you started with, and reset --hard.\n\nIndeed, but you must *know* that and you must know that you *can* do it.\n\nAs for undo rm -rf, it's not part of git and outside the scope of git.\n\n-- robin\n"},{"id":"58713","messageId":"fgt5jh$dei$1@ger.gmane.org","threadId":"10672","inReplyTo":"200711072032.48193.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-07T20:01:53Z","receivedAt":"2007-11-07T20:01:53Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robin Rosenberg wrote:\n\n> As for undo rm -rf, it's not part of git and outside the scope of git.\n\nUnless Mnemosyne or some other automatic backup solution is based on git as\nengine...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}