Re: [msysGit] Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Dave Bradley dbradl...@bell.net writes: Original #178 content G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an%ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + This added to my confusion as by right dq within dq should be formatted. I do not see any dq within dq here. Perhaps you need to count again to see which one pairs with which one. What I see are these three strings concatenated together: --pretty=format: (which does not need any dq) %an %ad (the dq protects 3 SPs inside) (an empty string inside the final dq pair) So the single parameter that begins with --pretty given to git log is exactly the same as what is inside the single dq pair in the following: --pretty=format:%an %ad A more conventional way to spell it may however be one of: --pretty=format:%an %ad --pretty=format:%an %ad -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Hi, Interesting discussion. However, the example below of three-spaces between %an and %ad in the example below resulted in the formatting of the output with the three spaces, but no dq's. Original #178 content G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an%ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + This added to my confusion as by right dq within dq should be formatted. (Yea right, these days its needs to be escaped. But haven't tried that.) In summary so far, it would appear that the --pretty. needs to be contained in double-quotes as a whole. This was the solution I applied to my problem. In the discussions I've seen more information requested as to the arguments provided to the execution class. I solved this issue as I made it work by experiment. I format the argument as a whole and don't have the space. IE. pretty=format:name:%an%nauthor:%ad%n. Regards -Original Message- From: Erik Faye-Lund Sent: Friday, May 02, 2014 2:23 PM To: Jonathan Nieder Cc: Dave Bradley ; GIT Mailing-list ; msysGit Subject: Re: [msysGit] Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad' On Fri, May 2, 2014 at 7:23 PM, Jonathan Nieder jrnie...@gmail.com wrote: (resending with the correct address for the Git for Windows developers. Sorry for the noise.) Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml As does it on Windows. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
#178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
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. There are a three additional comments, thank you to the contributors. The advise was to discuss upstream which meant nothing to me (again thanks to another contributor for clarification). Summary The issue reported is (in my opinion) a defect in argument processing (happens on Windows and Linux (as per another contributor)). The issue (in my opinion) is a defect for argument processing by Git. The decision (agreement or otherwise) I guess is for this upstream discussion. I appreciate the open-source git and its usage to the community. But this is owned by the discussion group and I doubt my involvement is wanted. So this will be my last communication on this issue. Context -- Over many years, I’ve used command-line on Unix/Linux/Windows in both hobby and professional modes. In the latter case the processing of arguments with spaces has often been the cause of defects (none expected behaviour) for newly introduced products. I’ve found no documentation about the pretty=format behaviour as described by the #178 issue. Also, there are many (but incomplete) google-it second-hand documents(?) about. So a document fix in the internet age is not necessarily the approach to solve an issue, as all those google-it items create fog. For this issue I was processing a git command to run in a GUI and happened upon it. The GUI (original design by me) allows interfacing with CVS, SVN, HG and maybe now GIT in a similar manner. The GUI holds the interfacing and access information and concatenates it onto the VCS command/sub-commands as appropriate for a request. Thus, the concatenated VCS request may be processed for copy-paste onto a command line window/terminal or (for my GUI) executed via a programming language’s command-line-execution class/function (Perl, Java, C,.). With the argument being further processed within git, it behaves in a manner that wasn’t expected. Thx Dave the Issue as reported 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). This is reproduced on a Windows command-line entry by putting double-quotes around the argument. (see below for various examples of pass, fail and testing around). The git argument parser appears to perform a split on spaces within the arguments passed to it also. This is not a normal behaviour for any parsing. Also, the split is happening within a string quote, it would appear (%an %ad). Even tried %20 to represent the space. Thx G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley dbradl...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley dbradl...@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.
Hmm, 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:\wxgit 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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml I think the intent was instead to pass five arguments (the third being '--pretty=format:%an %ad'). That means you shouldn't unquote before the space, or in other words that the space should be part of a quoted argument. On Windows, I believe the argument passing convention is more complicated. Programs can inspect the entire command line if they want to. But there's still an ambiguity in the command you passed: if I look at space-separated or double-quoted parts of the command line, it looks like git log --all --pretty=format: (no space) %an %ad (no space) -- pom.xml What's the right way to parse this? How can git tell whether %an %ad were meant to be separate arguments or not? In absence of a stronger convention I suspect the simplest rule is to mimic what a Unix shell does, where they are separate arguments because the space is not quoted. Cc-ing Windows folks in case they have more insight. Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
(resending with the correct address for the Git for Windows developers. Sorry for the noise.) Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml I think the intent was instead to pass five arguments (the third being '--pretty=format:%an %ad'). That means you shouldn't unquote before the space, or in other words that the space should be part of a quoted argument. On Windows, I believe the argument passing convention is more complicated. Programs can inspect the entire command line if they want to. But there's still an ambiguity in the command you passed: if I look at space-separated or double-quoted parts of the command line, it looks like git log --all --pretty=format: (no space) %an %ad (no space) -- pom.xml What's the right way to parse this? How can git tell whether %an %ad were meant to be separate arguments or not? In absence of a stronger convention I suspect the simplest rule is to mimic what a Unix shell does, where they are separate arguments because the space is not quoted. Cc-ing Windows folks in case they have more insight. Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: #178 parsing of pretty=format:%an %ad causes fatal: bad revision '%ad'
On Fri, May 2, 2014 at 7:23 PM, Jonathan Nieder jrnie...@gmail.com wrote: (resending with the correct address for the Git for Windows developers. Sorry for the noise.) Hi Dave, Dave Bradley wrote: G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml Mon Nov 23 03:09:17 2009 + Mon Nov 23 02:42:24 2009 + G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all --pretty=format:%an %ad -- pom.xml fatal: bad revision '%ad' On Linux, this example gets passed to git as six arguments: log --all --pretty=format:%an %ad -- pom.xml As does it on Windows. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
