From: Dave Bradley <dbradley2@bell.net>
To: <git@vger.kernel.org>
Subject: #178 parsing of pretty=format:"%an %ad" causes fatal: bad revision '%ad'
Date: Fri, 2 May 2014 07:50:25 -0400 [thread overview]
Message-ID: <BLU0-SMTP1116609FAC7E0C76123F929F430@phx.gbl> (raw)
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.x>git
log --all --pretty=format:"%an %ad" -- pom.xml
xxxx xxxx Mon Nov 23 03:09:17 2009 +0000
xxxx xxxx Mon Nov 23 02:42:24 2009 +0000
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
"--pretty=format:"%an %ad"" -- pom.xml
fatal: bad revision '%ad'
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
"--pretty=format:"%an" "%ad"" -- pom.xml
xxxx xxxx Mon Nov 23 03:09:17 2009 +0000
xxxx xxxx Mon Nov 23 02:42:24 2009 +0000
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
"--pretty=format:"%an" " %ad"" -- pom.xml
fatal: bad revision '%ad'
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.x>git log --all
"--pretty=format:"%an" "%ad"" -- pom.xml
xxxx xxxx Mon Nov 23 03:09:17 2009 +0000
xxxx xxxx Mon Nov 23 02:42:24 2009 +0000
next reply other threads:[~2014-05-02 11:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 11:50 Dave Bradley [this message]
2014-05-02 12:12 ` #178 parsing of pretty=format:"%an %ad" causes fatal: bad revision '%ad' Erik Faye-Lund
2014-05-02 17:18 ` Junio C Hamano
2014-05-02 17:22 ` Jonathan Nieder
2014-05-02 17:23 ` Jonathan Nieder
2014-05-02 18:23 ` Erik Faye-Lund
2014-05-04 10:14 ` [msysGit] " Dave Bradley
2014-05-05 23:02 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU0-SMTP1116609FAC7E0C76123F929F430@phx.gbl \
--to=dbradley2@bell.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.