Re: #178 parsing of pretty=format:"%an %ad" causes fatal: bad revision '%ad'

[Junio C Hamano <gitster@pobox.com>]

Erik Faye-Lund <kusmabite@gmail.com> writes:

> On Fri, May 2, 2014 at 1:50 PM, Dave Bradley <dbradley2@bell.net> wrote:
>> Hi,
>>
>> I’m very new to ‘git’ github. I reported the #178 issue in github and the
>> issue has been closed, I believe this means no further discussion.
>
> When you say "the #178 issue in github", you really mean "issue #178
> for Git for Windows on GitHub", available at
> https://github.com/msysgit/git/issues/178 for those interested.
>
> That issue tracker is for the Windows port of Git for Windows. It's
> intended to track breakages in Git for Windows compared to Git on, say
> Linux. It's not a general issue tracker for problems with Git. Still,
> it seems a lot of people think "I downloaded Git for Windows, and
> here's something that didn't work the way I expected it to, I'll file
> a bug". Those kinds of bug-reports usually gets closed quickly, as
> it's outside the scope of Git for Windows to decide how Git should
> behave - we try to make it behave consistently between Windows and
> Unixy-platforms.
>
> This is indeed the right forum to address your issue. So thank you for
> moving the discussion here.

Hmmmmmm, everything you said in the earlier paragraphs is correct,
but I am having a feeling that this is either an issue specific to
the Windows port, or more likely a user error, depending on who is
giving the extra dq quoting.  From the command line:

    $ git show --pretty='format:"%an %ad"'
    "Junio C Hamano Wed Apr 30 11:01:42 2014 -0700"

Because the 'format:' specifier requests to put dq around these two,
we respond by putting dq around these two, just as we were asked to
do.  The way to ask %an followed by SP followed by %ad and nothing
else is

    $ git show --pretty='format:%an %ad'
    Junio C Hamano Wed Apr 30 11:01:42 2014 -0700

Especially this part from the original tells me that this is a user
error and there is nothing wrong in either the generic Git or in the
Windows port.

    G:\w....x>git log --all "--pretty=format:"%an %ad"" -- pom.xml
    fatal: bad revision '%ad'

Separating the tokens on that command line, we would get:

    git
    log
    --all
    --pretty=format:%an
    %ad
    --
    pom.xml

So it told git to run the log subcommand with arguments that tells
it to "include all tips of refs to the starting set", "show them
using a custom format %an", "include %ad to the starting set",
"everything that follows are not revs but pathspecs", and then
finally "pom.xml is the pathspec to limit to paths the user is
interested in".  "%ad is not a rev" is perfectly valid.


You cannot take --pretty=format:"%ad %an" that you see in tutorials
and random web pages too literally.  The double quotes you see in
that example is our way to tell that "--pretty=format:%ad %an" (what
is inside these dq) is expected to be fed to Git as a single
argument.

The examples you see typically follow the convention to show what
you _would_ give to shell to achieve that, and shell's command line
parser needs these dq to make sure that the SP between %an and %ad
is not taken as an argument separator.

Your custom front-end may take a different approach to let you
specify what individual arguments are on your command line, and you
would have to follow its convention.  The user needs to be careful
about how shell quoting works on his/her command line, and that is
all, I would think.

Visiting an earlier part of the original issue report:

    Getting a fatal failure when using the following
    --pretty=format:"%an %ad" via a programmed execution from within
    a programming language. (Java using the execution capabilities
    puts the ' --pretty=format:"%an %ad" ' as an argument).

I take that "Java using ..." to mean that the user wants to see his
machinery eventually do an equivalent to:

	execl('git', 'git', 'log', '--pretty=format:%an %ad', ...);

but it somehow is getting

	execl('git', 'git', 'log', '--pretty=format:%an', '%ad', ...);

due to reason unknown to us that is not in the report.

Without knowing what the end-user input to the front-end that calls
into that "Java" machinery is and what the argument separating
convention that is employed by the front-end is, I cannot tell where
the single argument is split into two.  The problem may either be in
that front-end program and not in the end-user input.  Or the
problem may be in Windows port letting the Windows library split
command line at a funny point.  In any case, it does not sound like
it is a problem in Git.  If the command fed to the equivalent to
execl() above were not 'git' but any program, it will suffer from
the same issue.