{"thread":{"id":"46534","subject":"Suggestion: better error message when an ambiguous checkout is executed","startedAt":"2017-08-07T21:49:47Z","lastAt":"2017-09-12T06:53:24Z","messageCount":3,"participants":["Mahmoud Al-Qudsi","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"325767","messageId":"CACcTrKdzVCKUR8EfwhqBQR7vWzRqTLcwRJ_r-hx3VztD=xvNuQ@mail.gmail.com","threadId":"46534","inReplyTo":null,"subject":"Suggestion: better error message when an ambiguous checkout is executed","fromName":"Mahmoud Al-Qudsi","fromEmail":"mqudsi@neosmart.net","sentAt":"2017-08-07T21:49:18Z","receivedAt":"2017-08-07T21:49:47Z","isPatch":false,"sender":{"key":"mqudsi@neosmart.net","avatar":"https://gravatar.com/avatar/c2643dd7c6df61aed49d9f3d917ac6d61cafbbda5f9b1619f50d3b749dca415a?d=mp&s=160"},"body":"Hello,\n\nThe default git behavior when attempting to `git checkout xxx` for\nsome value of \"xxx\" that cannot be resolved to a single, unique\nfile/path/branch/tag/commit/etc is to display the following:\n\n> error: pathspec 'xxx' did not match any file(s) known to git\n\nUnfortunately, this is (IMHO) at best misleading when the actual case\nis that \"git could not unambiguously resolve pathspec xxx\"\n\nCan the case where xxx _was_ resolved but to more than one value be\nimproved in both utility and comprehensibility by providing an error\nmessage that\n\n1) indicates that xxx was a valid pathspec, but not a unique one\n2) provides a list of unique pathspecs that xxx matched against\n\ne.g. in the case where xxx is the name of a branch on both origin1 and\norigin2, it would be ideal if git could instead report\n\n> error: pathspec 'xxx' could not be uniquely resolved\n> xxx can refer to one of the following:\n> * branch origin1/xxx\n> * branch origin2/xxx\n\nor, less ideally but much simpler, only the first line of that message?\n\nThank you,\n\nMahmoud Al-Qudsi\nNeoSmart Technologies\n"},{"id":"325772","messageId":"xmqq8tivngkk.fsf@gitster.mtv.corp.google.com","threadId":"46534","inReplyTo":"CACcTrKdzVCKUR8EfwhqBQR7vWzRqTLcwRJ_r-hx3VztD=xvNuQ@mail.gmail.com","subject":"Re: Suggestion: better error message when an ambiguous checkout is executed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-07T22:44:43Z","receivedAt":"2017-08-07T22:44:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:\n\n> The default git behavior when attempting to `git checkout xxx` for\n> some value of \"xxx\" that cannot be resolved to a single, unique\n> file/path/branch/tag/commit/etc is to display the following:\n>\n>> error: pathspec 'xxx' did not match any file(s) known to git\n\nYes, it is true that the user may have wanted to instead checkout a\nbranch 'xxy' and misspelled it as 'xxx'.  Or the user may have more\nthan one remotes, from which there are remote-tracking branches for\n'xxx' branch.  Neither of these cases allow Git to interpret 'xxx'\nas a rev, and Git blindly thinks that 'xxx' must be a pathspec, and\nwants to ensure that such a path exists in the working tree (if\n'xxx' does not look like a wildcard or otherwise magic pathspec).\n\n> Unfortunately, this is (IMHO) at best misleading when the actual case\n> is that \"git could not unambiguously resolve pathspec xxx\"\n\nThe actual case you want to address is \"git could not tell that the\nuser meant 'xxx' as a revision, even though the end user meant it as\nsuch\".\n\n> Can the case where xxx _was_ resolved but to more than one value be\n> improved in both utility and comprehensibility by providing an error\n> message that\n>\n> 1) indicates that xxx was a valid pathspec, but not a unique one\n\nJust the terminology, you are no longer talking about a pathspec.\nYou are talking about a rev; i.e. when refs/remotes/origin[12]/xxx \nexist, the user may have meant 'xxx' as a rev, but Git is not allowed\nto pick one of them randomly.\n\nIt would be nice to take this case into account.\n\nNote that if refs/remotes/origin/xxy exists and the user misspelled\nit as 'xxx', you would still get the same \"(because 'xxx' cannot be\na rev, it must be a pathspec) pathspec 'xxx' did not match...\" error\nmessage, though, so there might not be much point in special casing\n\"more than one potentially matching revs\" case over \"there is no\npotentially matching revs\" case, though.\n\n> 2) provides a list of unique pathspecs that xxx matched against\n>\n> e.g. in the case where xxx is the name of a branch on both origin1 and\n> origin2, it would be ideal if git could instead report\n>\n>> error: pathspec 'xxx' could not be uniquely resolved\n>> xxx can refer to one of the following:\n>> * branch origin1/xxx\n>> * branch origin2/xxx\n\nAgain you are talking about \"revs\", not pathspecs.  The above (with\ntweak to the wrong terminology) would work as a better error message\n*if* there is no chance that the user meant 'xxx' as a pathspec,\ni.e. \"I want to overwrite the files in the working tree that matches\nthe pathspec 'xxx' with matching contents from the index\".\n\nSo a possible implementation approach would be\n\n - to let the current code do what it is doing\n\n - except that you add new code immediately before the code that\n   issues 'xxx' did not match (i.e. the code already checked that\n   'xxx' taken as a pathspec does not match anything, and about to\n   give the error message but hasn't done so just yet).\n\n - your new code \n\n   . checks if 'xxx' could be an attempt to refer to a rev but\n     insufficiently spelled out (e.g. both origin[12]/xxx exists, or\n     for a bonus point, a similarly named origin/xxy exists and\n     could be a typo).\n\n   . if the above check found something, then you report it and\n     terminate without complaining \"pathspec 'xxx' did not\n     match...\"\n\n   . on the other hand, if the above check did not find anything,\n     then you let the current code issue the same error message as\n     before.\n\n\n"},{"id":"327877","messageId":"xmqqo9qg1k82.fsf@gitster.mtv.corp.google.com","threadId":"46534","inReplyTo":"xmqq8tivngkk.fsf@gitster.mtv.corp.google.com","subject":"Re: Suggestion: better error message when an ambiguous checkout is executed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-12T06:53:17Z","receivedAt":"2017-09-12T06:53:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:\n>\n>> The default git behavior when attempting to `git checkout xxx` for\n>> some value of \"xxx\" that cannot be resolved to a single, unique\n>> file/path/branch/tag/commit/etc is to display the following:\n> ...\n> So a possible implementation approach would be\n>\n>  - to let the current code do what it is doing\n>\n>  - except that you add new code immediately before the code that\n>    issues 'xxx' did not match (i.e. the code already checked that\n>    'xxx' taken as a pathspec does not match anything, and about to\n>    give the error message but hasn't done so just yet).\n>\n>  - your new code \n>\n>    . checks if 'xxx' could be an attempt to refer to a rev but\n>      insufficiently spelled out (e.g. both origin[12]/xxx exists, or\n>      for a bonus point, a similarly named origin/xxy exists and\n>      could be a typo).\n>\n>    . if the above check found something, then you report it and\n>      terminate without complaining \"pathspec 'xxx' did not\n>      match...\"\n>\n>    . on the other hand, if the above check did not find anything,\n>      then you let the current code issue the same error message as\n>      before.\n\nI was sweeping my mailbox to collect loose ends that haven't been\ntied down, and noticed that this topic does not seem to have reached\na conclusion.  Do we want to reboot the effort?  Or should we just\nthrow it in the #leftoverbits bin for now?\n\nThanks.\n"}]}