{"thread":{"id":"24744","subject":"[PATCH] reset: Better warning message on git reset --mixed ","startedAt":"2010-08-14T19:34:59Z","lastAt":"2010-08-16T04:23:35Z","messageCount":18,"participants":["Ævar Arnfjörð Bjarmason","Jonathan Nieder","Junio C Hamano","Miles Bader","David Fries","Ralf Ebert"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"148103","messageId":"1281814499-11797-1-git-send-email-avarab@gmail.com","threadId":"24744","inReplyTo":null,"subject":"[PATCH] reset: Better warning message on git reset --mixed ","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-14T19:34:59Z","receivedAt":"2010-08-14T19:34:59Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"When you call \"git reset --mixed \" git will complain that using\nmixed with paths is deprecated:\n\n warning: --mixed option is deprecated with paths.\n\nThat doesn't tell the user why it's deprecated, or what he should use\ninstead. Expand on the warning and tell the user to just omit --mixed:\n\n warning: --mixed is redundant with paths, use 'git reset ' instead.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n\nOn Sat, Aug 14, 2010 at 19:12, Ralf Ebert wrote:\n> On 14.08.2010 20:55, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> On Sat, Aug 14, 2010 at 18:40, Ralf Ebert  wrote:\n>>>\n>>> On 14.08.2010 17:23, Ævar Arnfjörð Bjarmason wrote:\n>>>>\n>>>> So what should I use instead? 0e5a7faa which introduced it doesn't say.\n>>>\n>>> It doesn't currently exist, but I'm pretty sure it should be called 'git\n>>> unstage' :)\n>>\n>> Then perhaps it should be undeprecated? If what you say is correct\n>> it's been whining about that since 2007 with no alternative, while\n>> doing what I mean when I run it.\n>\n> Sorry, I misremembered '--mixed' again, '--mixed' is the default and it\n> doesn't complain if you just omit it, and if I read&tried right, 'git reset\n> ' does the same as 'git reset --mixed '.\n\nRight you are, if only we had a manpage to explain this or something >:)\n\nAnyway, I think the warning could be better, here's a patch to\nimplement that. We could also warn on a plain \"git reset --mixed\"\nsince it's also redundant, but that would be adding something new so I\nhaven't done that here.\n\n builtin/reset.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex 1283068..a7878d4 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -318,7 +318,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t * affecting the working tree nor HEAD. */\n \tif (i < argc) {\n \t\tif (reset_type == MIXED)\n-\t\t\twarning(\"--mixed option is deprecated with paths.\");\n+\t\t\twarning(\"--mixed is redundant with paths, use 'git reset ' instead.\");\n \t\telse if (reset_type != NONE)\n \t\t\tdie(\"Cannot do %s reset with paths.\",\n \t\t\t\t\treset_type_names[reset_type]);\n-- \n1.7.2.1.339.g9c5d4\n"},{"id":"148106","messageId":"20100814210505.GA2372@burratino","threadId":"24744","inReplyTo":"1281814499-11797-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-14T21:05:06Z","receivedAt":"2010-08-14T21:05:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n\n> Anyway, I think the warning could be better, here's a patch to\n> implement that. We could also warn on a plain \"git reset --mixed\"\n> since it's also redundant, but that would be adding something new so I\n> haven't done that here.\n\nThat seems backwards --- it is not actually the redundancy that leads\nto this warning (and I hope we never add such a warning to save people\ntyping).\n\nInstead, I had assumed the idea was that some day “git reset --mixed\n” will be forbidden, eliminating a potential ambiguity in that\nargument and saving high-level scripts from needing -- at the end of\n“git reset --mixed --”.\n\n> +++ b/builtin/reset.c\n> @@ -318,7 +318,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n> \t * affecting the working tree nor HEAD. */\n> \tif (i < argc) {\n> \t\tif (reset_type == MIXED)\n> -\t\t\twarning(\"--mixed option is deprecated with paths.\");\n> +\t\t\twarning(\"--mixed is redundant with paths, use 'git reset ' instead.\");\n\nMaybe:\n\n warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n"},{"id":"148119","messageId":"7vvd7chcj4.fsf@alter.siamese.dyndns.org","threadId":"24744","inReplyTo":"20100814210505.GA2372@burratino","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-15T01:47:59Z","receivedAt":"2010-08-15T01:47:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Maybe:\n>\n> warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n\nThat sounds helpful.\n\nWe've been saying this form is deprecated since 1.5.4; a better\nalternative may be to make this into an error in the next release,\nthough.\n"},{"id":"148121","messageId":"87tymwzjbk.fsf@catnip.gol.com","threadId":"24744","inReplyTo":"7vvd7chcj4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-08-15T02:43:59Z","receivedAt":"2010-08-15T02:43:59Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n>> warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n>\n> That sounds helpful.\n>\n> We've been saying this form is deprecated since 1.5.4; a better\n> alternative may be to make this into an error in the next release,\n> though.\n\nOn a similar note, how about a more helpful error message for\n\"git reset --hard PATH\"? It took me _ages_ to figure out that I\nneeded to do \"git checkout PATH\" to get that effect...\n\ne.g.:\n\n $ git reset --hard load-lua.cc\n fatal: --hard cannot be used with paths; use \"git checkout -- instead\"\n\n-Miles\n\n-- \nBrain, n. An apparatus with which we think we think.\n"},{"id":"148133","messageId":"AANLkTin3zyPvs3GjOt3=q6dOofFA2ba0sBAzt3=Ka1Wn@mail.gmail.com","threadId":"24744","inReplyTo":"87tymwzjbk.fsf@catnip.gol.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-15T08:38:16Z","receivedAt":"2010-08-15T08:38:16Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Aug 15, 2010 at 02:43, Miles Bader wrote:\n> Junio C Hamano writes:\n>>>  warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n>>\n>> That sounds helpful.\n>>\n>> We've been saying this form is deprecated since 1.5.4; a better\n>> alternative may be to make this into an error in the next release,\n>> though.\n>\n> On a similar note, how about a more helpful error message for\n> \"git reset --hard PATH\"?  It took me _ages_ to figure out that I\n> needed to do \"git checkout PATH\" to get that effect...\n>\n> e.g.:\n>\n>   $ git reset --hard load-lua.cc\n>   fatal: --hard cannot be used with paths; use \"git checkout -- instead\"\n\nDo you have suggestions for alternatives for \"git reset [ --soft |\n--merge | --keep ] -- \" too? Since I'm working on this anyway I\nmight roll that in.\n"},{"id":"148130","messageId":"1281861800-424-1-git-send-email-avarab@gmail.com","threadId":"24744","inReplyTo":"20100814210505.GA2372@burratino","subject":"[PATCH v2] reset: Better warning message on git reset --mixed ","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-15T08:43:20Z","receivedAt":"2010-08-15T08:43:20Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"When you call \"git reset --mixed \" git will complain that using\nmixed with paths is deprecated:\n\n warning: --mixed option is deprecated with paths.\n\nThat doesn't tell the user why it's deprecated, or what he should use\ninstead. Expand on the warning and tell the user to just omit --mixed:\n\n warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n\nThe exact wording of the warning was suggested by Jonathan Nieder.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n\nOn Sat, Aug 14, 2010 at 21:05, Jonathan Nieder wrote:\n> Maybe:\n>\n>  warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n\nThat's better, thanks. Here's an amended version, and with tests this\ntime.\n\n builtin/reset.c | 2 +-\n t/t7112-reset-messages.sh | 33 +++++++++++++++++++++++++++++++++\n 2 files changed, 34 insertions(+), 1 deletions(-)\n create mode 100755 t/t7112-reset-messages.sh\n\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex 1283068..0037be4 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -318,7 +318,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t * affecting the working tree nor HEAD. */\n \tif (i < argc) {\n \t\tif (reset_type == MIXED)\n-\t\t\twarning(\"--mixed option is deprecated with paths.\");\n+\t\t\twarning(\"--mixed with paths is deprecated; use 'git reset -- ' instead.\");\n \t\telse if (reset_type != NONE)\n \t\t\tdie(\"Cannot do %s reset with paths.\",\n \t\t\t\t\treset_type_names[reset_type]);\ndiff --git a/t/t7112-reset-messages.sh b/t/t7112-reset-messages.sh\nnew file mode 100755\nindex 0000000..6f2669b\n--- /dev/null\n+++ b/t/t7112-reset-messages.sh\n@@ -0,0 +1,33 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Ævar Arnfjörð Bjarmason\n+#\n+\n+test_description='git reset warning and error messages'\n+\n+. ./test-lib.sh\n+\n+test_expect_success 'setup {err,out}-expect' \"\n+\tcat >err-expect <' instead.\n+EOF\n+\tcat >out-expect < warning' '\n+\t# Not test_commit() due to \"ambiguous argument [..] both revision\n+\t# and filename\"\n+\techo stuff >hlagh &&\n+\tgit add hlagh &&\n+\tgit commit -m\"adding stuff\" hlagh &&\n+\techo more stuff >hlagh &&\n+\tgit add hlagh &&\n+\ttest_must_fail git reset --mixed hlagh >out 2>err &&\n+\ttest_cmp err-expect err &&\n+\ttest_cmp out-expect out\n+'\n+\n+test_done\n-- \n1.7.2.1.339.gfad93\n"},{"id":"148132","messageId":"20100815130245.GB15631@spacedout.fries.net","threadId":"24744","inReplyTo":"87tymwzjbk.fsf@catnip.gol.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"David Fries","fromEmail":"david@fries.net","sentAt":"2010-08-15T13:02:45Z","receivedAt":"2010-08-15T13:02:45Z","isPatch":true,"sender":{"key":"david@fries.net","avatar":"https://avatars.githubusercontent.com/u/2767875?v=4"},"body":"On Sun, Aug 15, 2010 at 11:43:59AM +0900, Miles Bader wrote:\n> On a similar note, how about a more helpful error message for\n> \"git reset --hard PATH\"? It took me _ages_ to figure out that I\n> needed to do \"git checkout PATH\" to get that effect...\n\nThere's also the mixed reset in a bare repository message that could\nuse an update.\n\n-- \nDavid Fries \nhttp://fries.net/~david/ (PGP encryption key available)\n\n>From fe5837d9222a621c081e22685db65adab32207f6 Mon Sep 17 00:00:00 2001\nFrom: David Fries \nDate: Fri, 2 Jul 2010 09:12:47 -0500\nSubject: [PATCH] reset --mixed message update, tell the user what will work\n\nInstead of,\nfatal: mixed reset is not allowed in a bare repository\nprint,\nfatal: mixed reset is not allowed in a bare repository, use --soft\nTo tell the user what they can do, instead of just what they can't.\n---\n builtin/reset.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex 1283068..ebbefe0 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -332,7 +332,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\tsetup_work_tree();\n \n \tif (reset_type == MIXED && is_bare_repository())\n-\t\tdie(\"%s reset is not allowed in a bare repository\",\n+\t\tdie(\"%s reset is not allowed in a bare repository, use --soft\",\n \t\t reset_type_names[reset_type]);\n \n \t/* Soft reset does not touch the index file nor the working tree\n-- \n1.7.1\n"},{"id":"148144","messageId":"7vr5hzg1u1.fsf@alter.siamese.dyndns.org","threadId":"24744","inReplyTo":"AANLkTin3zyPvs3GjOt3=q6dOofFA2ba0sBAzt3=Ka1Wn@mail.gmail.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-15T18:36:38Z","receivedAt":"2010-08-15T18:36:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Regarding the various modes that are forbidden with \"reset\", I've been\nwondering if we can do things differently.\n\nIf you want to reset the index at selected paths, don't use any option, as\nnothing but --mixed makes sense. Hence we deprecated use of --mixed when\nused this way. But if _it_ makes sense, why deprecate it? What harm\nwould it do if we took it silently?\n\nIIRC, the reasoning that lead to the deprecation was that allowing --mixed\nmay give a false impression to confused users that other mode options also\nmight be usable with pathspec, e.g. \"reset --soft [] \".\nIt obviously should barf loudly, as there is no way to move the HEAD to a\nnamed commit without touching the index and the worktree at only specified\npaths, but then the error message belongs to --soft, not --mixed.\n\nAlso \"reset --hard [] -- \" is forbidden in a repository\nwith a working tree, but it is clear that what the user wanted to do with\nthat unsupported command was what \"checkout [] -- \"\nwould have done.\n\nWhat if we:\n\n - change \"reset --hard [] -- \" to internally run the\n moral equivalent \"checkout\" without complaining;\n\n - change \"reset --mixed [] -- \" to do the same thing as\n it has always done without complaining; and\n\n - make sure \"reset --soft [] -- \" barfs loudly.\n\nDo people see major downside?\n"},{"id":"148145","messageId":"20100815194913.GB1856@burratino","threadId":"24744","inReplyTo":"7vr5hzg1u1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-15T19:49:13Z","receivedAt":"2010-08-15T19:49:13Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> If you want to reset the index at selected paths, don't use any option, as\n> nothing but --mixed makes sense. Hence we deprecated use of --mixed when\n> used this way. But if _it_ makes sense, why deprecate it? What harm\n> would it do if we took it silently?\n\nNothing major. It would be the same inconsistency as we currently have\nbetween \"checkout -- \" and \"checkout --\":\none updates the HEAD (or rather, for \"reset\", the current branch),\nwhile the other doesn’t.\n\nSo my preference is to make \"reset --foo\" not take a pathspec, but it\nis not a strong one.\n"},{"id":"148148","messageId":"AANLkTik+yGn_0PR9uO2_EsZgQPW187P4qmZx4fJSbAWO@mail.gmail.com","threadId":"24744","inReplyTo":"7vr5hzg1u1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-15T20:51:03Z","receivedAt":"2010-08-15T20:51:03Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Aug 15, 2010 at 18:36, Junio C Hamano wrote:\n\n> What if we:\n>\n>  - change \"reset --hard [] -- \" to internally run the\n>   moral equivalent \"checkout\" without complaining;\n>\n>  - change \"reset --mixed [] -- \" to do the same thing as\n>   it has always done without complaining; and\n>\n>  - make sure \"reset --soft [] -- \" barfs loudly.\n>\n> Do people see major downside?\n\nGenerally I'd like to see Git move towards have a more internally\nconsistent UI and less warts.\n\nDoing what you suggest would make git-reset(1) more internally\nconsistent, while duplicating the git-checkout functionality.\n\nSo it's a question of whether git-reset should do all reset-y things\nwithout complaining, even when that infringes on git-checkout's\ndomain.\n\nI don't know which should be picked, but it's something to\nconsider.\n\nOne thing I'd like to see is some documentation showing how we'd like\nGit to act if we didn't have to worry about backwards compatibility. I\nsometimes see little warts like mixing of cached/index/stage, but I\nhaven't seen any plan for these sort of things. Are we planning to\nchange some of these things in the future? If so when, and what should\nbe changed?\n\nIt's hard to say whether a UI change like this makes sense without the\nbigger picture.\n"},{"id":"148149","messageId":"1281906304.32195.26.camel@lucy.SSG5-Serial-WLAN","threadId":"24744","inReplyTo":"7vr5hzg1u1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Ralf Ebert","fromEmail":"ralf@ralfebert.de","sentAt":"2010-08-15T21:05:04Z","receivedAt":"2010-08-15T21:05:04Z","isPatch":true,"sender":{"key":"ralf@ralfebert.de","avatar":null},"body":"> Regarding the various modes that are forbidden with \"reset\", I've been\n> wondering if we can do things differently.\n\nAfter being very happy about finding the\n'soft-mixed-hard-path-cheat-sheet' table in 0e5a7fa (mentioned in Ævars\nmessage that triggered the discussion)\n\nreset: --soft --mixed --hard -- \nHEAD X X X -\nindex - X X X\nfiles - - X -\n\nI was wondering:\n\nWouldn't the common reset soft/mixed/hard with path/commit operations\nbecome a lot more intuitive by separating the \"(1) copy [partially] from\nHEAD to index [to working tree]\" operation and the \"(2) change HEAD and\ndo (1)\" operation? Just as a very rough scribble of what I mean, like\nthis:\n\ngit wipe [] # git reset []; git checkout []\ngit wipe [] --index-only # git reset [--mixed] []\n\ngit set-head # git reset --soft []\ngit set-head --wipe # git reset --hard []\ngit set-head --wipe-index-only # git reset --mixed []\n\n(I know that git reset can do more than that, but this is everything I\never wanted as porcelain-only user from git reset, thought maybe the\nidea could be of use without being fully elaborated)\n\n--\nRalf\n"},{"id":"148152","messageId":"7viq3bfrjy.fsf@alter.siamese.dyndns.org","threadId":"24744","inReplyTo":"20100815194913.GB1856@burratino","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-15T22:18:41Z","receivedAt":"2010-08-15T22:18:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Nothing major. It would be the same inconsistency as we currently have\n> between \"checkout -- \" and \"checkout --\":\n> one updates the HEAD (or rather, for \"reset\", the current branch),\n> while the other doesn’t.\n\nWhat do you mean by inconsistency? One is checking out the whole branch\nto work on the named branch, while the other is checking out individual\npaths out of branch to work on them in the current branch.\n\nThey are entirely different operations.\n"},{"id":"148153","messageId":"7veidzfre0.fsf@alter.siamese.dyndns.org","threadId":"24744","inReplyTo":"AANLkTik+yGn_0PR9uO2_EsZgQPW187P4qmZx4fJSbAWO@mail.gmail.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-15T22:22:15Z","receivedAt":"2010-08-15T22:22:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> So it's a question of whether git-reset should do all reset-y things\n> without complaining, even when that infringes on git-checkout's\n> domain.\n\nI'm not sure about \"domain\"; do not think we should also forbid for the\nsame argument \"git reset --soft\" because it violates update-ref's domain?\n\nI changed my mind; I do not like \"git reset --hard -- \"\ndoing \"checkout -- \", unless we limit this when \nis not given (or perhaps when is the same as HEAD). Otherwise it\nwould make things harder to explain. So let's forget about it now.\n"},{"id":"148161","messageId":"20100816001211.GD3296@burratino","threadId":"24744","inReplyTo":"1281906304.32195.26.camel@lucy.SSG5-Serial-WLAN","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-16T00:12:11Z","receivedAt":"2010-08-16T00:12:11Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ralf Ebert wrote:\n\n> git wipe [] # git reset []; git checkout []\n\ngit checkout HEAD -- .\n\nSo:\n\nrepository ---> index ---> work tree\n\nLimited by paths\n================\n\n r -> i: git reset -- \n i -> w: git checkout -- \n r -> w: git checkout -- \n\nUpdating head symref\n====================\n\n r -> r: git checkout HEAD^0 && git reset --soft && git checkout \n r -> i: git checkout HEAD^0 && git reset --mixed && git checkout \n r -> w: git checkout \n\nResetting branch tip\n====================\n\n r -> r: git reset --soft \n r -> i: git reset --mixed \n r -> w: git reset --hard \n\n“git checkout --no-update” and “git checkout --no-update --keep-index”\ndo not sound very useful to me, so I am not suggesting adding them.\n"},{"id":"148163","messageId":"AANLkTim=TM_3aXMSSN1-vovdc3z6QNR15KHujiJ-wH4_@mail.gmail.com","threadId":"24744","inReplyTo":"AANLkTik+yGn_0PR9uO2_EsZgQPW187P4qmZx4fJSbAWO@mail.gmail.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-08-16T00:59:44Z","receivedAt":"2010-08-16T00:59:44Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Mon, Aug 16, 2010 at 5:51 AM, Ævar Arnfjörð Bjarmason\n wrote:\n> So it's a question of whether git-reset should do all reset-y things\n> without complaining, even when that infringes on git-checkout's\n> domain.\n\nOf course one question is: why is this \"git-checkout's domain\" in the\nfirst place?\n\nFrom a UI perspective this functionality doesn't seem to make any more\nsense in checkout -- and perhaps _less_ -- than it does in git-reset.\n\"git-checkout \" seems like a tacked-on-to-make-cvs-users-happy\nwart rather than a natural part of git-checkout.\n\nI know that as a beginning git user, I always tried to use \"git-reset\n--hard \", because that sort of made sense in my mental model of\ngit commands, only to be confused when it didn't work. The fact that\none actually needed to to do git-checkout instead was confusing.\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"148169","messageId":"AANLkTi=ddi_fek3NxF=ESM6HP3Myn6sa1xfsWMyNCUFB@mail.gmail.com","threadId":"24744","inReplyTo":"AANLkTim=TM_3aXMSSN1-vovdc3z6QNR15KHujiJ-wH4_@mail.gmail.com","subject":"Re: [PATCH] reset: Better warning message on git reset --mixed ","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-16T01:13:51Z","receivedAt":"2010-08-16T01:13:51Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Aug 16, 2010 at 00:59, Miles Bader wrote:\n> On Mon, Aug 16, 2010 at 5:51 AM, Ævar Arnfjörð Bjarmason\n> wrote:\n>> So it's a question of whether git-reset should do all reset-y things\n>> without complaining, even when that infringes on git-checkout's\n>> domain.\n>\n> Of course one question is:  why is this \"git-checkout's domain\" in the\n> first place?\n>\n> From a UI perspective this functionality doesn't seem to make any more\n> sense in checkout -- and perhaps _less_ -- than it does in git-reset.\n> \"git-checkout \" seems like a tacked-on-to-make-cvs-users-happy\n> wart rather than a natural part of git-checkout.\n>\n> I know that as a beginning git user, I always tried to use \"git-reset\n> --hard \", because that sort of made sense in my mental model of\n> git commands, only to be confused when it didn't work.  The fact that\n> one actually needed to to do git-checkout instead was confusing.\n\nYeah, maybe one command to reset a file to various states makes more\nsense than a singular \"checking it out\".\n\nAnyway, this is the sort of thing I was alluding to, it won't do to\nmake micro-changes to the UI without considering the bigger picture.\n"},{"id":"148173","messageId":"7vmxsndy5b.fsf@alter.siamese.dyndns.org","threadId":"24744","inReplyTo":"1281861800-424-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v2] reset: Better warning message on git reset --mixed ","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-16T03:39:12Z","receivedAt":"2010-08-16T03:39:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> When you call \"git reset --mixed \" git will complain that using\n> mixed with paths is deprecated:\n>\n> warning: --mixed option is deprecated with paths.\n>\n> That doesn't tell the user why it's deprecated, or what he should use\n> instead. Expand on the warning and tell the user to just omit --mixed:\n>\n> warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n>\n> The exact wording of the warning was suggested by Jonathan Nieder.\n>\n> Signed-off-by: Ævar Arnfjörð Bjarmason \n> ---\n>\n> On Sat, Aug 14, 2010 at 21:05, Jonathan Nieder wrote:\n>> Maybe:\n>>\n>>  warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n>\n> That's better, thanks. Here's an amended version, and with tests this\n> time.\n\nWhile the new message is an improvement, I do not think the added test\nthat checks the exact wording is good.\n\nThink for 5 seconds what the expected code change would be to break that\ntest. I can only think of two realistic cases. (1) Command line parsing\nis broken and \"reset --mixed \" does not go through the codepath\nthat produces this warning anymore; (2) we deem that we had the\ndeprecation long enough and error out on this usage; or (3) Somebody comes\nup with an even better wording but the string in this test still expects\nsuboptimal warning.\n\nWhen we change this to an error, that is a behaviour change (it will\nchange the exit status as well), and it would be Ok to force the person\nwho does such a change to update the test. But (3) shows that this test\nis making it harder for people to improve the wording than necessary;\nisn't it sufficient to check if any warning is issued at all?\n\nI personally do not think this deserves to consume a new test number,\nwhich is rather a scarce resource.\n\n> diff --git a/t/t7112-reset-messages.sh b/t/t7112-reset-messages.sh\n> new file mode 100755\n> index 0000000..6f2669b\n> --- /dev/null\n> +++ b/t/t7112-reset-messages.sh\n> @@ -0,0 +1,33 @@\n> ...\n> +test_expect_success 'git reset --mixed warning' '\n> +\t# Not test_commit() due to \"ambiguous argument [..] both revision\n> +\t# and filename\"\n\nHuh?\n"},{"id":"148176","messageId":"AANLkTimHQ7c=F8y50Keq1eo5aC+D9fuaF7Eye5GJj1t-@mail.gmail.com","threadId":"24744","inReplyTo":"7vmxsndy5b.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] reset: Better warning message on git reset --mixed ","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-16T04:23:35Z","receivedAt":"2010-08-16T04:23:35Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Aug 16, 2010 at 03:39, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason   writes:\n>\n>> When you call \"git reset --mixed \" git will complain that using\n>> mixed with paths is deprecated:\n>>\n>>     warning: --mixed option is deprecated with paths.\n>>\n>> That doesn't tell the user why it's deprecated, or what he should use\n>> instead. Expand on the warning and tell the user to just omit --mixed:\n>>\n>>     warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n>>\n>> The exact wording of the warning was suggested by Jonathan Nieder.\n>>\n>> Signed-off-by: Ævar Arnfjörð Bjarmason \n>> ---\n>>\n>> On Sat, Aug 14, 2010 at 21:05, Jonathan Nieder wrote:\n>>> Maybe:\n>>>\n>>>  warning: --mixed with paths is deprecated; use 'git reset -- ' instead\n>>\n>> That's better, thanks. Here's an amended version, and with tests this\n>> time.\n>\n> While the new message is an improvement, I do not think the added test\n> that checks the exact wording is good.\n>\n> Think for 5 seconds what the expected code change would be to break that\n> test.  I can only think of two realistic cases.  (1) Command line parsing\n> is broken and \"reset --mixed \" does not go through the codepath\n> that produces this warning anymore; (2) we deem that we had the\n> deprecation long enough and error out on this usage; or (3) Somebody comes\n> up with an even better wording but the string in this test still expects\n> suboptimal warning.\n>\n> When we change this to an error, that is a behaviour change (it will\n> change the exit status as well), and it would be Ok to force the person\n> who does such a change to update the test.  But (3) shows that this test\n> is making it harder for people to improve the wording than necessary;\n> isn't it sufficient to check if any warning is issued at all?\n\nI thought we might test for deprecation warnings, since they're a step\nabove general warnings as they imply a deprecation cycle.\n\nI'm just used to a codebase where every single warning message of that\nsort is explicitly tested for, so I mostly did that out of habit.\n\n> I personally do not think this deserves to consume a new test number,\n> which is rather a scarce resource.\n\nJust drop the test file from the patch, I don't think it's really\nneeded, and maybe drop the patch altogether. I don't know what we want\nto do about this reset behavior in general.\n\n>> diff --git a/t/t7112-reset-messages.sh b/t/t7112-reset-messages.sh\n>> new file mode 100755\n>> index 0000000..6f2669b\n>> --- /dev/null\n>> +++ b/t/t7112-reset-messages.sh\n>> @@ -0,0 +1,33 @@\n>> ...\n>> +test_expect_success 'git reset --mixed warning' '\n>> +     # Not test_commit() due to \"ambiguous argument [..] both revision\n>> +     # and filename\"\n>\n> Huh?\n\nI think I forgot that test_commit could take two args there.\n"}]}