{"thread":{"id":"47283","subject":"[PATCH v2] gitcli: tweak \"man gitcli\" for clarity","startedAt":"2017-11-21T21:29:26Z","lastAt":"2017-11-25T03:02:36Z","messageCount":19,"participants":["Robert P. J. Day","Kevin Daudt","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"333167","messageId":"alpine.LFD.2.21.1711211626460.26166@localhost.localdomain","threadId":"47283","inReplyTo":null,"subject":"[PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-21T21:27:59Z","receivedAt":"2017-11-21T21:29:26Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"No major changes, just some rewording and showing some variations of\ngeneral Git commands.\n\nSigned-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n\n---\n\ndiff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\nindex 9f13266a6..d690d1ff0 100644\n--- a/Documentation/gitcli.txt\n+++ b/Documentation/gitcli.txt\n@@ -13,7 +13,7 @@ gitcli\n DESCRIPTION\n -----------\n\n-This manual describes the convention used throughout Git CLI.\n+This manual describes the conventions used throughout Git CLI.\n\n Many commands take revisions (most often \"commits\", but sometimes\n \"tree-ish\", depending on the context and command) and paths as their\n@@ -32,32 +32,35 @@ arguments.  Here are the rules:\n    between the HEAD commit and the work tree as a whole\".  You can say\n    `git diff HEAD --` to ask for the latter.\n\n- * Without disambiguating `--`, Git makes a reasonable guess, but errors\n-   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n+ * Without a disambiguating `--`, Git makes a reasonable guess, but can\n+   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n    file called HEAD in your work tree, `git diff HEAD` is ambiguous, and\n    you have to say either `git diff HEAD --` or `git diff -- HEAD` to\n    disambiguate.\n +\n When writing a script that is expected to handle random user-input, it is\n a good practice to make it explicit which arguments are which by placing\n-disambiguating `--` at appropriate places.\n+a disambiguating `--` at appropriate places.\n\n  * Many commands allow wildcards in paths, but you need to protect\n-   them from getting globbed by the shell.  These two mean different\n-   things:\n+   them from getting globbed by the shell.  The following commands have\n+   two different meanings:\n +\n --------------------------------\n $ git checkout -- *.c\n+\n $ git checkout -- \\*.c\n+$ git checkout -- \"*.c\"\n+$ git checkout -- '*.c'\n --------------------------------\n +\n-The former lets your shell expand the fileglob, and you are asking\n-the dot-C files in your working tree to be overwritten with the version\n-in the index.  The latter passes the `*.c` to Git, and you are asking\n-the paths in the index that match the pattern to be checked out to your\n-working tree.  After running `git add hello.c; rm hello.c`, you will _not_\n-see `hello.c` in your working tree with the former, but with the latter\n-you will.\n+The first command lets your shell expand the fileglob, and you are asking\n+the dot-C files in your working tree to be overwritten with the version in\n+the index.  The latter three variations pass the `*.c` to Git, and you are\n+asking the paths in the index that match the pattern to be checked out to\n+your working tree.  After running `git add hello.c; rm hello.c`, you will\n+_not_ see `hello.c` in your working tree with the first command, but with\n+the latter three variations, you will.\n\n  * Just as the filesystem '.' (period) refers to the current directory,\n    using a '.' as a repository name in Git (a dot-repository) is a relative\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333170","messageId":"20171121214552.GB16418@alpha.vpn.ikke.info","threadId":"47283","inReplyTo":"alpine.LFD.2.21.1711211626460.26166@localhost.localdomain","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-21T21:45:52Z","receivedAt":"2017-11-21T21:45:58Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:\n> No major changes, just some rewording and showing some variations of\n> general Git commands.\n> \n> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> \n> ---\n> \n> diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\n> index 9f13266a6..d690d1ff0 100644\n> --- a/Documentation/gitcli.txt\n> +++ b/Documentation/gitcli.txt\n> @@ -13,7 +13,7 @@ gitcli\n>  DESCRIPTION\n>  -----------\n> \n> -This manual describes the convention used throughout Git CLI.\n> +This manual describes the conventions used throughout Git CLI.\n> \n>  Many commands take revisions (most often \"commits\", but sometimes\n>  \"tree-ish\", depending on the context and command) and paths as their\n> @@ -32,32 +32,35 @@ arguments.  Here are the rules:\n>     between the HEAD commit and the work tree as a whole\".  You can say\n>     `git diff HEAD --` to ask for the latter.\n> \n> - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n\n'Can' error out implies that it sometimes would not error out when there\nis ambiguity. Are there situation where git does not error out in that\ncase?\n\n>     file called HEAD in your work tree, `git diff HEAD` is ambiguous, and\n>     you have to say either `git diff HEAD --` or `git diff -- HEAD` to\n>     disambiguate.\n>  +\n>  When writing a script that is expected to handle random user-input, it is\n>  a good practice to make it explicit which arguments are which by placing\n> -disambiguating `--` at appropriate places.\n> +a disambiguating `--` at appropriate places.\n> \n>   * Many commands allow wildcards in paths, but you need to protect\n> -   them from getting globbed by the shell.  These two mean different\n> -   things:\n> +   them from getting globbed by the shell.  The following commands have\n> +   two different meanings:\n>  +\n>  --------------------------------\n>  $ git checkout -- *.c\n> +\n>  $ git checkout -- \\*.c\n> +$ git checkout -- \"*.c\"\n> +$ git checkout -- '*.c'\n>  --------------------------------\n>  +\n> -The former lets your shell expand the fileglob, and you are asking\n> -the dot-C files in your working tree to be overwritten with the version\n> -in the index.  The latter passes the `*.c` to Git, and you are asking\n> -the paths in the index that match the pattern to be checked out to your\n> -working tree.  After running `git add hello.c; rm hello.c`, you will _not_\n> -see `hello.c` in your working tree with the former, but with the latter\n> -you will.\n> +The first command lets your shell expand the fileglob, and you are asking\n> +the dot-C files in your working tree to be overwritten with the version in\n> +the index.  The latter three variations pass the `*.c` to Git, and you are\n> +asking the paths in the index that match the pattern to be checked out to\n> +your working tree.  After running `git add hello.c; rm hello.c`, you will\n> +_not_ see `hello.c` in your working tree with the first command, but with\n> +the latter three variations, you will.\n> \n>   * Just as the filesystem '.' (period) refers to the current directory,\n>     using a '.' as a repository name in Git (a dot-repository) is a relative\n> \n> -- \n> \n> ========================================================================\n> Robert P. J. Day                                 Ottawa, Ontario, CANADA\n>                         http://crashcourse.ca\n> \n> Twitter:                                       http://twitter.com/rpjday\n> LinkedIn:                               http://ca.linkedin.com/in/rpjday\n> ========================================================================\n"},{"id":"333171","messageId":"alpine.LFD.2.21.1711211646050.26665@localhost.localdomain","threadId":"47283","inReplyTo":"20171121214552.GB16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-21T21:47:42Z","receivedAt":"2017-11-21T21:49:10Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Tue, 21 Nov 2017, Kevin Daudt wrote:\n\n> On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:\n> > No major changes, just some rewording and showing some variations of\n> > general Git commands.\n> >\n> > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> >\n> > ---\n> >\n> > diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\n> > index 9f13266a6..d690d1ff0 100644\n> > --- a/Documentation/gitcli.txt\n> > +++ b/Documentation/gitcli.txt\n> > @@ -13,7 +13,7 @@ gitcli\n> >  DESCRIPTION\n> >  -----------\n> >\n> > -This manual describes the convention used throughout Git CLI.\n> > +This manual describes the conventions used throughout Git CLI.\n> >\n> >  Many commands take revisions (most often \"commits\", but sometimes\n> >  \"tree-ish\", depending on the context and command) and paths as their\n> > @@ -32,32 +32,35 @@ arguments.  Here are the rules:\n> >     between the HEAD commit and the work tree as a whole\".  You can say\n> >     `git diff HEAD --` to ask for the latter.\n> >\n> > - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> > -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> > + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> > +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n>\n> 'Can' error out implies that it sometimes would not error out when\n> there is ambiguity. Are there situation where git does not error out\n> in that case?\n\n  i would say (based on my limited knowledge) that if the heuristic\nkicks in and works fine, then things will work. i think it's fair to\nsay that git \"can\" error out if the heuristic fails.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333173","messageId":"20171121220409.GC16418@alpha.vpn.ikke.info","threadId":"47283","inReplyTo":"alpine.LFD.2.21.1711211646050.26665@localhost.localdomain","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-21T22:04:09Z","receivedAt":"2017-11-21T22:04:17Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Tue, Nov 21, 2017 at 04:47:42PM -0500, Robert P. J. Day wrote:\n> On Tue, 21 Nov 2017, Kevin Daudt wrote:\n> \n> > On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:\n> > > No major changes, just some rewording and showing some variations of\n> > > general Git commands.\n> > >\n> > > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> > >\n> > > ---\n> > >\n> > > diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\n> > > index 9f13266a6..d690d1ff0 100644\n> > > --- a/Documentation/gitcli.txt\n> > > +++ b/Documentation/gitcli.txt\n> > > @@ -13,7 +13,7 @@ gitcli\n> > >  DESCRIPTION\n> > >  -----------\n> > >\n> > > -This manual describes the convention used throughout Git CLI.\n> > > +This manual describes the conventions used throughout Git CLI.\n> > >\n> > >  Many commands take revisions (most often \"commits\", but sometimes\n> > >  \"tree-ish\", depending on the context and command) and paths as their\n> > > @@ -32,32 +32,35 @@ arguments.  Here are the rules:\n> > >     between the HEAD commit and the work tree as a whole\".  You can say\n> > >     `git diff HEAD --` to ask for the latter.\n> > >\n> > > - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> > > -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> > > + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> > > +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n> >\n> > 'Can' error out implies that it sometimes would not error out when\n> > there is ambiguity. Are there situation where git does not error out\n> > in that case?\n> \n>   i would say (based on my limited knowledge) that if the heuristic\n> kicks in and works fine, then things will work. i think it's fair to\n> say that git \"can\" error out if the heuristic fails.\n> \n> rday\n\nIn most cases that I'm aware of, you have to be explicit. If for example\nyou want to refer to a file that's not in the working tree, you have to\nuse '--'.  Even with heuristics, it would still have to error out when\nit's ambiguous what the user meant.\n\nSo the way you worded it implies that there are situations where git\nknows there are multiple things the user could have meant, but it would\nnot error out in that case.\n\nKevin\n\n"},{"id":"333177","messageId":"alpine.LFD.2.21.1711211711001.28430@localhost.localdomain","threadId":"47283","inReplyTo":"20171121220409.GC16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-21T22:12:16Z","receivedAt":"2017-11-21T22:13:43Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Tue, 21 Nov 2017, Kevin Daudt wrote:\n\n> On Tue, Nov 21, 2017 at 04:47:42PM -0500, Robert P. J. Day wrote:\n> > On Tue, 21 Nov 2017, Kevin Daudt wrote:\n> >\n> > > On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:\n> > > > No major changes, just some rewording and showing some variations of\n> > > > general Git commands.\n> > > >\n> > > > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> > > >\n> > > > ---\n> > > >\n> > > > diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\n> > > > index 9f13266a6..d690d1ff0 100644\n> > > > --- a/Documentation/gitcli.txt\n> > > > +++ b/Documentation/gitcli.txt\n> > > > @@ -13,7 +13,7 @@ gitcli\n> > > >  DESCRIPTION\n> > > >  -----------\n> > > >\n> > > > -This manual describes the convention used throughout Git CLI.\n> > > > +This manual describes the conventions used throughout Git CLI.\n> > > >\n> > > >  Many commands take revisions (most often \"commits\", but sometimes\n> > > >  \"tree-ish\", depending on the context and command) and paths as their\n> > > > @@ -32,32 +32,35 @@ arguments.  Here are the rules:\n> > > >     between the HEAD commit and the work tree as a whole\".  You can say\n> > > >     `git diff HEAD --` to ask for the latter.\n> > > >\n> > > > - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> > > > -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> > > > + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> > > > +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n> > >\n> > > 'Can' error out implies that it sometimes would not error out when\n> > > there is ambiguity. Are there situation where git does not error out\n> > > in that case?\n> >\n> >   i would say (based on my limited knowledge) that if the heuristic\n> > kicks in and works fine, then things will work. i think it's fair to\n> > say that git \"can\" error out if the heuristic fails.\n> >\n> > rday\n>\n> In most cases that I'm aware of, you have to be explicit. If for\n> example you want to refer to a file that's not in the working tree,\n> you have to use '--'.  Even with heuristics, it would still have to\n> error out when it's ambiguous what the user meant.\n>\n> So the way you worded it implies that there are situations where git\n> knows there are multiple things the user could have meant, but it\n> would not error out in that case.\n\n  all right, i will ponder this ... open to suggestions. i would have\nto examine the heuristic itself, wondering if it can make the wrong\ndecision on occasion.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333260","messageId":"alpine.LFD.2.21.1711220453290.3814@DESKTOP-1GPMCEJ","threadId":"47283","inReplyTo":"20171121214552.GB16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-22T09:55:12Z","receivedAt":"2017-11-22T09:56:42Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Tue, 21 Nov 2017, Kevin Daudt wrote:\n\n> On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:\n> > No major changes, just some rewording and showing some variations of\n> > general Git commands.\n> >\n> > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> >\n> > ---\n> >\n> > diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\n> > index 9f13266a6..d690d1ff0 100644\n> > --- a/Documentation/gitcli.txt\n> > +++ b/Documentation/gitcli.txt\n> > @@ -13,7 +13,7 @@ gitcli\n> >  DESCRIPTION\n> >  -----------\n> >\n> > -This manual describes the convention used throughout Git CLI.\n> > +This manual describes the conventions used throughout Git CLI.\n> >\n> >  Many commands take revisions (most often \"commits\", but sometimes\n> >  \"tree-ish\", depending on the context and command) and paths as their\n> > @@ -32,32 +32,35 @@ arguments.  Here are the rules:\n> >     between the HEAD commit and the work tree as a whole\".  You can say\n> >     `git diff HEAD --` to ask for the latter.\n> >\n> > - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> > -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> > + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> > +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n>\n> 'Can' error out implies that it sometimes would not error out when\n> there is ambiguity. Are there situation where git does not error out\n> in that case?\n\n  even if there is ambiguity, will git actually \"error out\"? i have a\ngit repo with a file called \"Gemfile\", so i created a branch called\n\"Gemfile\", and when i ran:\n\n  $ git checkout Gemfile\n\ngit switched to the branch. so even with the ambiguity, git obviously\nhas some sort of precedence order it checks. so what are the rules\nhere?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333261","messageId":"xmqq3756txeg.fsf@gitster.mtv.corp.google.com","threadId":"47283","inReplyTo":"alpine.LFD.2.21.1711220453290.3814@DESKTOP-1GPMCEJ","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-22T10:34:15Z","receivedAt":"2017-11-22T10:34:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n\n> git repo with a file called \"Gemfile\", so i created a branch called\n> \"Gemfile\", and when i ran:\n>\n>   $ git checkout Gemfile\n>\n> git switched to the branch. so even with the ambiguity, git obviously\n> has some sort of precedence order it checks. so what are the rules\n> here?\n\n31b83f36 (\"Merge branch 'nd/checkout-disambiguation'\", 2016-09-26)\nshould have made it clear that the \"checkout\" command has a\nconvenience special case.\n\n\n"},{"id":"333265","messageId":"alpine.LFD.2.21.1711220616230.11319@DESKTOP-1GPMCEJ","threadId":"47283","inReplyTo":"xmqq3756txeg.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-22T11:19:23Z","receivedAt":"2017-11-22T11:20:53Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Wed, 22 Nov 2017, Junio C Hamano wrote:\n\n> \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n>\n> > git repo with a file called \"Gemfile\", so i created a branch called\n> > \"Gemfile\", and when i ran:\n> >\n> >   $ git checkout Gemfile\n> >\n> > git switched to the branch. so even with the ambiguity, git\n> > obviously has some sort of precedence order it checks. so what are\n> > the rules here?\n>\n> 31b83f36 (\"Merge branch 'nd/checkout-disambiguation'\", 2016-09-26)\n> should have made it clear that the \"checkout\" command has a\n> convenience special case.\n\n  ok, then i'm still curious about git examples that actually fail due\nto an inability to disambiguate.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333266","messageId":"20171122114133.GD16418@alpha.vpn.ikke.info","threadId":"47283","inReplyTo":"alpine.LFD.2.21.1711220616230.11319@DESKTOP-1GPMCEJ","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-22T11:41:33Z","receivedAt":"2017-11-22T11:41:39Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Wed, Nov 22, 2017 at 06:19:23AM -0500, Robert P. J. Day wrote:\n> On Wed, 22 Nov 2017, Junio C Hamano wrote:\n> \n> > \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n> >\n> > > git repo with a file called \"Gemfile\", so i created a branch called\n> > > \"Gemfile\", and when i ran:\n> > >\n> > >   $ git checkout Gemfile\n> > >\n> > > git switched to the branch. so even with the ambiguity, git\n> > > obviously has some sort of precedence order it checks. so what are\n> > > the rules here?\n> >\n> > 31b83f36 (\"Merge branch 'nd/checkout-disambiguation'\", 2016-09-26)\n> > should have made it clear that the \"checkout\" command has a\n> > convenience special case.\n> \n>   ok, then i'm still curious about git examples that actually fail due\n> to an inability to disambiguate.\n> \n> rday\n\nHere is an example with git diff\n\n    $ git init git-disambiguate\n    $ cd git-disambiguate\n    $ echo 1 >foo && git add foo && git commit -m foo\n    $ git branch foo\n    $ echo 2 >>foo && git add foo && git commit -m foo2\n    $ echo 3 >>foo\n\n    $ git diff foo\n    fatal: ambiguous argument 'foo': both revision and filename\n    Use '--' to separate paths from revisions, like this:\n    'git <command> [<revision>...] -- [<file>...]'\n    \n    $ git diff HEAD foo\n    fatal: ambiguous argument 'foo': both revision and filename\n    Use '--' to separate paths from revisions, like this:\n    'git <command> [<revision>...] -- [<file>...]'\n\n    $ git diff HEAD -- foo\n    diff --git a/foo b/foo\n    index 1191247..01e79c3 100644\n    --- a/foo\n    +++ b/foo\n    @@ -1,2 +1,3 @@\n     1\n     2\n    +3\n\n    $ git diff HEAD foo --\n    diff --git a/foo b/foo\n    index 1191247..d00491f 100644\n    --- a/foo\n    +++ b/foo\n    @@ -1,2 +1 @@\n     1\n    -2\n \n"},{"id":"333267","messageId":"alpine.LFD.2.21.1711220645580.12052@DESKTOP-1GPMCEJ","threadId":"47283","inReplyTo":"20171122114133.GD16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-22T11:46:30Z","receivedAt":"2017-11-22T11:47:59Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Wed, 22 Nov 2017, Kevin Daudt wrote:\n\n> On Wed, Nov 22, 2017 at 06:19:23AM -0500, Robert P. J. Day wrote:\n> > On Wed, 22 Nov 2017, Junio C Hamano wrote:\n> >\n> > > \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n> > >\n> > > > git repo with a file called \"Gemfile\", so i created a branch called\n> > > > \"Gemfile\", and when i ran:\n> > > >\n> > > >   $ git checkout Gemfile\n> > > >\n> > > > git switched to the branch. so even with the ambiguity, git\n> > > > obviously has some sort of precedence order it checks. so what are\n> > > > the rules here?\n> > >\n> > > 31b83f36 (\"Merge branch 'nd/checkout-disambiguation'\", 2016-09-26)\n> > > should have made it clear that the \"checkout\" command has a\n> > > convenience special case.\n> >\n> >   ok, then i'm still curious about git examples that actually fail due\n> > to an inability to disambiguate.\n> >\n> > rday\n>\n> Here is an example with git diff\n>\n>     $ git init git-disambiguate\n>     $ cd git-disambiguate\n>     $ echo 1 >foo && git add foo && git commit -m foo\n>     $ git branch foo\n>     $ echo 2 >>foo && git add foo && git commit -m foo2\n>     $ echo 3 >>foo\n>\n>     $ git diff foo\n>     fatal: ambiguous argument 'foo': both revision and filename\n>     Use '--' to separate paths from revisions, like this:\n>     'git <command> [<revision>...] -- [<file>...]'\n>\n>     $ git diff HEAD foo\n>     fatal: ambiguous argument 'foo': both revision and filename\n>     Use '--' to separate paths from revisions, like this:\n>     'git <command> [<revision>...] -- [<file>...]'\n>\n>     $ git diff HEAD -- foo\n>     diff --git a/foo b/foo\n>     index 1191247..01e79c3 100644\n>     --- a/foo\n>     +++ b/foo\n>     @@ -1,2 +1,3 @@\n>      1\n>      2\n>     +3\n>\n>     $ git diff HEAD foo --\n>     diff --git a/foo b/foo\n>     index 1191247..d00491f 100644\n>     --- a/foo\n>     +++ b/foo\n>     @@ -1,2 +1 @@\n>      1\n>     -2\n\n  fair enough, i'll go back and reword to refer to actual\ndisambiguation errors.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333358","messageId":"20171123000346.GA8718@sigill","threadId":"47283","inReplyTo":"20171121214552.GB16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-23T00:03:46Z","receivedAt":"2017-11-23T00:03:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 21, 2017 at 10:45:52PM +0100, Kevin Daudt wrote:\n\n> > - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> > -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> > + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> > +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n> \n> 'Can' error out implies that it sometimes would not error out when there\n> is ambiguity. Are there situation where git does not error out in that\n> case?\n\nI read the rest of the thread, and I think the question here is not\nabout Git's behavior, but about parsing this sentence.\n\nWithout a \"--\" Git can sometimes do what you want. Or it may error out,\nif what you asked for is ambiguous. And that sentence is trying to cover\nthose cases separately, and the \"can\" only applies to the ambiguous\ncase.\n\nIt's pretty clear to me as it is, but maybe we can write it differently.\nLike:\n\n  Without a disambiguating `--`, Git makes a reasonable guess. If it\n  cannot guess (because your request is ambiguous), then it will error\n  out.\n\n-Peff\n"},{"id":"333367","messageId":"xmqqtvxlraxx.fsf@gitster.mtv.corp.google.com","threadId":"47283","inReplyTo":"20171123000346.GA8718@sigill","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-23T02:22:18Z","receivedAt":"2017-11-23T02:22:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I read the rest of the thread, and I think the question here is not\n> about Git's behavior, but about parsing this sentence.\n>\n> Without a \"--\" Git can sometimes do what you want. Or it may error out,\n> if what you asked for is ambiguous. And that sentence is trying to cover\n> those cases separately, and the \"can\" only applies to the ambiguous\n> case.\n>\n> It's pretty clear to me as it is, but maybe we can write it differently.\n> Like:\n>\n>   Without a disambiguating `--`, Git makes a reasonable guess. If it\n>   cannot guess (because your request is ambiguous), then it will error\n>   out.\n\nSplitting it into two sentences like you did makes it even clearer,\nI would think.\n\n"},{"id":"333376","messageId":"alpine.LFD.2.21.1711230241260.11944@localhost.localdomain","threadId":"47283","inReplyTo":"20171123000346.GA8718@sigill","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-23T07:45:44Z","receivedAt":"2017-11-23T07:47:16Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Wed, 22 Nov 2017, Jeff King wrote:\n\n> On Tue, Nov 21, 2017 at 10:45:52PM +0100, Kevin Daudt wrote:\n>\n> > > - * Without disambiguating `--`, Git makes a reasonable guess, but errors\n> > > -   out and asking you to disambiguate when ambiguous.  E.g. if you have a\n> > > + * Without a disambiguating `--`, Git makes a reasonable guess, but can\n> > > +   error out, asking you to disambiguate when ambiguous.  E.g. if you have a\n> >\n> > 'Can' error out implies that it sometimes would not error out when there\n> > is ambiguity. Are there situation where git does not error out in that\n> > case?\n>\n> I read the rest of the thread, and I think the question here is not\n> about Git's behavior, but about parsing this sentence.\n>\n> Without a \"--\" Git can sometimes do what you want. Or it may error out,\n> if what you asked for is ambiguous. And that sentence is trying to cover\n> those cases separately, and the \"can\" only applies to the ambiguous\n> case.\n>\n> It's pretty clear to me as it is, but maybe we can write it differently.\n> Like:\n>\n>   Without a disambiguating `--`, Git makes a reasonable guess. If it\n>   cannot guess (because your request is ambiguous), then it will error\n>   out.\n\n  ok, i'll give this another try, given that there are two independent\npoints to be made here:\n\n1) even without the \"--\", git can generally parse the command and do\nthe right thing (or do a *valid* thing, given its heuristics)\n\n2) occasionally, without the \"--\", the command is really and truly\nambiguous, at which point git will fail and tell you to disambiguate\n\n  not the wording i will use, but can we agree that those are the two\npoints to be made here?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"333381","messageId":"20171123135155.GA8231@sigill","threadId":"47283","inReplyTo":"alpine.LFD.2.21.1711230241260.11944@localhost.localdomain","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-23T13:51:55Z","receivedAt":"2017-11-23T13:52:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 23, 2017 at 02:45:44AM -0500, Robert P. J. Day wrote:\n\n> > It's pretty clear to me as it is, but maybe we can write it differently.\n> > Like:\n> >\n> >   Without a disambiguating `--`, Git makes a reasonable guess. If it\n> >   cannot guess (because your request is ambiguous), then it will error\n> >   out.\n> \n>   ok, i'll give this another try, given that there are two independent\n> points to be made here:\n> \n> 1) even without the \"--\", git can generally parse the command and do\n> the right thing (or do a *valid* thing, given its heuristics)\n> \n> 2) occasionally, without the \"--\", the command is really and truly\n> ambiguous, at which point git will fail and tell you to disambiguate\n> \n>   not the wording i will use, but can we agree that those are the two\n> points to be made here?\n\nYep, I think so.\n\n-Peff\n"},{"id":"333392","messageId":"20171123205503.GE16418@alpha.vpn.ikke.info","threadId":"47283","inReplyTo":"20171123135155.GA8231@sigill","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-23T20:55:03Z","receivedAt":"2017-11-23T20:55:09Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Thu, Nov 23, 2017 at 08:51:55AM -0500, Jeff King wrote:\n> On Thu, Nov 23, 2017 at 02:45:44AM -0500, Robert P. J. Day wrote:\n> \n> > > It's pretty clear to me as it is, but maybe we can write it differently.\n> > > Like:\n> > >\n> > >   Without a disambiguating `--`, Git makes a reasonable guess. If it\n> > >   cannot guess (because your request is ambiguous), then it will error\n> > >   out.\n> > \n> >   ok, i'll give this another try, given that there are two independent\n> > points to be made here:\n> > \n> > 1) even without the \"--\", git can generally parse the command and do\n> > the right thing (or do a *valid* thing, given its heuristics)\n> > \n> > 2) occasionally, without the \"--\", the command is really and truly\n> > ambiguous, at which point git will fail and tell you to disambiguate\n> > \n> >   not the wording i will use, but can we agree that those are the two\n> > points to be made here?\n> \n> Yep, I think so.\n> \n> -Peff\n\nJust for completeness, as it is somewhat covered by point 1 already, but\nthere are cases where there is no real ambiguity but you are required to\nadd '--' to tell git that it should not look for the file in the working\ntree:\n\n  $ git show abc123 deleted_file.txt\n  fatal: ambiguous argument 'deleted_file.txt':\n  unknown revision or path not in the working tree.\n  Use '--' to separate paths from revisions, like this:\n  'git <command> [<revision>...] -- [<file>...]'\n\nThere might be good reasons why this is, but I don't consider this to be\nactually ambiguous: there is no branch called 'deleted_file.txt' and git\ncould know that the files exists in the mentioned commit, so it should\nbe pretty clear what is meant.\n\nMight be worth documenting this.\n\nKevin\n"},{"id":"333402","messageId":"xmqq7eugqykq.fsf@gitster.mtv.corp.google.com","threadId":"47283","inReplyTo":"20171123205503.GE16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-24T01:01:41Z","receivedAt":"2017-11-24T01:01:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Daudt <me@ikke.info> writes:\n\n> Just for completeness, as it is somewhat covered by point 1 already, but\n> there are cases where there is no real ambiguity but you are required to\n> add '--' to tell git that it should not look for the file in the working\n> tree:\n>\n>   $ git show abc123 deleted_file.txt\n>   fatal: ambiguous argument 'deleted_file.txt':\n>   unknown revision or path not in the working tree.\n>   Use '--' to separate paths from revisions, like this:\n>   'git <command> [<revision>...] -- [<file>...]'\n>\n> There might be good reasons why this is, but I don't consider this to be\n> actually ambiguous: there is no branch called 'deleted_file.txt' and git\n> could know that the files exists in the mentioned commit, so it should\n> be pretty clear what is meant.\n\nI know you understand all of this, but your \"git could\" needs to be\nexamined carefully.\n\nThe same can be said for \"git log master deleted_file.txt\" whose\nintention is to refer to a file that the user _thinks_ existed once\nin the past but may never have been there.\n\nSurely, \"git could\" know if it runs \"git log master\" to the root of\nthe history to see if it ever existed.  Also, against \"git log\nmaster next deleted_file.txt\", \"git could\" do the same traversal from\ntwo tips of the history to check that.  But it requires us to do the\nsame work twice to materialize that \"git could\".\n\nActually the second example is a lot worse (and that is why I am\nbringing it up).  If git does spend cycles to realize that \"git\ncould\", for consistency, it must also check if \"next\" is unambiguous\nbetween a path or a rev, i.e. it must dig history from \"master\" and\nsee if \"next\" appears as a path ever in the history, and if so, die\nwith \"ambiguous argument\".\n\nThe message \"unknown revision or path not in the working tree.\"\nclearly shows why we decided to ask.  Even if deleted_file.txt could\nhave been a valid path somewhere in the history, \"not in the working\ntree\" is the condition we check to see if it is unambiguous.  And we\nstop and ask when it cannot be proven cheaply that it is not.\n\n\"git stops and asks when ambiguous\" is a white lie to explain the\nsafety feature in a way that is easier to understand.  If somebody\nwants to make the documentation more \"technically correct\", the\ncondition is not \"when ambiguous\", but \"when git cannot prove it is\nnot unambiguous with inexpensive tests\".\n\nIIRC, I think Peff mentioned in this or nearby thread that we do not\nwant to spell out the implementation details and leave the exact\nconditions vague on purpose, and that principle probably would apply\nhere, too.  We might later discover that checking not just the working\ntree but also for the index to see if user meant by deleted_file.txt\na path and not a revision is not overly expensive, for example, and\nat that point, we are still trying to prove that it is unambiguously\na path and not a rev with inexpensive tests.\n"},{"id":"333452","messageId":"20171124181254.GC29190@sigill","threadId":"47283","inReplyTo":"20171123205503.GE16418@alpha.vpn.ikke.info","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-24T18:12:54Z","receivedAt":"2017-11-24T18:13:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 23, 2017 at 09:55:03PM +0100, Kevin Daudt wrote:\n\n> > > >   Without a disambiguating `--`, Git makes a reasonable guess. If it\n> > > >   cannot guess (because your request is ambiguous), then it will error\n> > > >   out.\n> [...]\n> > > 1) even without the \"--\", git can generally parse the command and do\n> > > the right thing (or do a *valid* thing, given its heuristics)\n> > > \n> > > 2) occasionally, without the \"--\", the command is really and truly\n> > > ambiguous, at which point git will fail and tell you to disambiguate\n> [...]\n> \n> Just for completeness, as it is somewhat covered by point 1 already, but\n> there are cases where there is no real ambiguity but you are required to\n> add '--' to tell git that it should not look for the file in the working\n> tree:\n\nRight, I was focused on what the sentence _currently_ said, and didn't\nthink about other cases. The \"cannot guess\" case is not just due to\nambiguity, but may be due to other heuristics.\n\nI _think_ the only one is the \"does it exist in the working tree\" rule\nyou found, but I'm not sure we'd want to commit ourselves to never\nchanging that.\n\nYou could make my suggestion correct by putting \"e.g.,\" or \"for example\"\nat the front of the parentheses. ;)\n\nThere is an open question of how carefully we want to document it, but I\nthink the strategy so far has been:\n\n - if you want to be careful, use \"--\"\n\n - if you don't, git will use black magic to guess, but that magic is\n   subject to change, so don't rely on it\n\nI don't mind documenting the current magic as long as the \"don't rely on\nit\" part is made clear.\n\n>   $ git show abc123 deleted_file.txt\n>   fatal: ambiguous argument 'deleted_file.txt':\n>   unknown revision or path not in the working tree.\n>   Use '--' to separate paths from revisions, like this:\n>   'git <command> [<revision>...] -- [<file>...]'\n> \n> There might be good reasons why this is, but I don't consider this to be\n> actually ambiguous: there is no branch called 'deleted_file.txt' and git\n> could know that the files exists in the mentioned commit, so it should\n> be pretty clear what is meant.\n\nFor that command, yes. But when the command is \"git log\", do we really\nwant to dig through all of history to see if anybody ever mentions\n\"deleted_file\"?\n\nI'm not sure if we want to get into having different rules for different\ncontexts. Not to mention that this really mixes up the layers; you\ncannot know what the whole command line means until you decide what\nabc123 means and examine it, which may in turn be influenced by other\noptions. E.g., given:\n\n  git log --no-merges A..B deleted_file.txt\n\nwe have to actually do the no-merges log of A..B to see if\ndeleted_file.txt is in there.\n\n-Peff\n"},{"id":"333453","messageId":"20171124181639.GD29190@sigill","threadId":"47283","inReplyTo":"xmqq7eugqykq.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-24T18:16:39Z","receivedAt":"2017-11-24T18:16:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 24, 2017 at 10:01:41AM +0900, Junio C Hamano wrote:\n\n> Actually the second example is a lot worse (and that is why I am\n> bringing it up).  If git does spend cycles to realize that \"git\n> could\", for consistency, it must also check if \"next\" is unambiguous\n> between a path or a rev, i.e. it must dig history from \"master\" and\n> see if \"next\" appears as a path ever in the history, and if so, die\n> with \"ambiguous argument\".\n\nI just sent a similar response before reading this, and agree with\neverything you said.\n\nBut I wanted to point out this \"we must also look for ambiguities\"\nargument, because I totally missed it in my response. And it's much more\ndamning, I think, because it means you can never short-cut the easy\ncases and say \"OK, we found the path, therefore we can stop our\ntraversal early\". To behave consistently, you have to always do the\nwhole traversal twice.\n\n-Peff\n"},{"id":"333467","messageId":"xmqqpo87kqm3.fsf@gitster.mtv.corp.google.com","threadId":"47283","inReplyTo":"20171124181254.GC29190@sigill","subject":"Re: [PATCH v2] gitcli: tweak \"man gitcli\" for clarity","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-25T03:02:28Z","receivedAt":"2017-11-25T03:02:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> There is an open question of how carefully we want to document it, but I\n> think the strategy so far has been:\n>\n>  - if you want to be careful, use \"--\"\n>\n>  - if you don't, git will use black magic to guess, but that magic is\n>    subject to change, so don't rely on it\n>\n> I don't mind documenting the current magic as long as the \"don't rely on\n> it\" part is made clear.\n\nYes, taken with \"git log master\" example where if we want to say\n\"this truly cannot be ambiguous\" and end up digging \"git log HEAD --\"\nto ensure there is no path that match 'master' ever existed, I would\nprefer not to say a lot more about \"black magic\" and yet still going\ninto the precise details.\n\nOn the other hand, of course we do not want to cast in stone the\nprecise details of the current \"black magic\" implementation that is\nsubject to change.\n\nA description of \"black magic\" that is without details, i.e. the one\nthat focuses on the spirit and not the exact design, would be...\n\n    Without \"--\", Git tries to find a point between two arguments on\n    (or at the beginning or the end of) the command line, where\n    every argument before it are likely to be a revision (and\n    unlikely to be a path) and every argument after it are likely to\n    be a path (and unlikely to be a revision) with \"black magic\".\n    If there is no such point, you'd be asked to disambiguate.\n\n    The \"black magic\" would use 4 combinations that results from\n    two tests.  \n\n    A. Is it likely to be a revision (yes/no)?\n    B. Is it likely to be a path (yes/no)?\n\n    If both are true, it is am ambigous command line.  If neither is\n    true, it is likely a typo (e.g. \"git log naster\" when the user\n    meant 'master', or \"git log Nakefile\" when the user meant\n    'Makefile').  If only one is true, Git thinks that the command\n    line is unambigous and goes ahead with its decision.\n\n    Git will not spend excess amount of cycles to make these two\n    tests, so there can be misidentification.  Two easy to\n    understand examples are:\n\n    - If you have a file 'naster' in your working tree and said \"git\n      log naster\", test A _could_ notice that there is a slightly\n      different name 'master' that could be a revision that you\n      meant, and ask you to disambiguate in case you made a typo.\n      Because test A (deliberately) is not overly thorough, Git does\n      not flag it as a possible ambiguity.\n\n    - If you had a file whose name is \"Nakefile\" in HEAD but you\n      just removed it, \"git log Nakefile\" may actually be a valid\n      and unambigous request to use Nakefile as a path, but in order\n      to notice that possibility, Git has to not just check if the\n      working tree has such a path, but also in the index and HEAD\n      (and if the removal was older, then it has to do an internal\n      \"git log\" to see what paths ever existed in the past, which is\n      ridiculous).  Because test B (deliberately) is not overly\n      thorough, Git would refuse to use it as either a revision or a\n      path without disambiguation.\n\n"}]}