git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* [PATCH 0/1] p4: fix "Not a valid object name HEAD0" when unshelving
@ 2019-05-10 15:33 Mike Mueller via GitGitGadget
  2019-05-10 15:33 ` [PATCH 1/1] p4 unshelve: fix "Not a valid object name HEAD0" Mike Mueller via GitGitGadget
  2019-05-28 18:15 ` [PATCH v2 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
  0 siblings, 2 replies; 7+ messages in thread
From: Mike Mueller via GitGitGadget @ 2019-05-10 15:33 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

git p4 unshelve was failing with "fatal: Not a valid object name HEAD0" and
"Command failed: git cat-file commit HEAD^0" on certain systems e.g. git
version 2.21.0.windows.1 + python 2.7.16

It seems that certain python pOpen implementations drop the ^ character when
invoked using a string instead of an array as first argument, which is what
is done by extractLogMessageFromGitCommit.

Solution is to use the array format of passing the command to fOpen, which
is preferred (see https://docs.python.org/2/library/subprocess.html) and is
used in other parts of this code anyway.

Mike Mueller (1):
  p4 unshelve: fix "Not a valid object name HEAD0"

 git-p4.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: aeb582a98374c094361cba1bd756dc6307432c42
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-183%2Fmdymike%2Fmaint-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-183/mdymike/maint-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/183
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/1] p4 unshelve: fix "Not a valid object name HEAD0"
  2019-05-10 15:33 [PATCH 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
@ 2019-05-10 15:33 ` Mike Mueller via GitGitGadget
  2019-05-15  5:25   ` Junio C Hamano
  2019-05-28 18:15 ` [PATCH v2 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
  1 sibling, 1 reply; 7+ messages in thread
From: Mike Mueller via GitGitGadget @ 2019-05-10 15:33 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Mike Mueller

From: Mike Mueller <mike.mueller@moodys.com>

git p4 unshelve was failing with these errors on Windows:

fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0

(git version 2.21.0.windows.1, python 2.7.16)

The pOpen call used by git-p4 to invoke the git command can take either a
string or an array as a first argument.  The array form is preferred
however the extractLogMessageFromGitCommit method was using the string
form, which makes the caller responsible for escaping the command text
appropriately (see https://docs.python.org/2/library/subprocess.html)

Somewhat ironically, the carat character is the escape character in
Windows and so should be escaped (HEAD^^0).  Without the extra carat, the
OS was passing an escaped 0 to the git command instead, and the git
command was rejecting the invalid object name "HEAD0"

The behaviour can be confirmed by typing ECHO HEAD^0 at the command-
prompt, which emits HEAD0.

The solution is simply to use the array format of passing the command to
fOpen, which is preferred and used in other parts of this code anyway.

Signed-off-by: Mike Mueller <mike.mueller@moodys.com>
---
 git-p4.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-p4.py b/git-p4.py
index 5b79920f46..0b5bfcbc5e 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):
 
     ## fixme: title is first line of commit, not 1st paragraph.
     foundTitle = False
-    for log in read_pipe_lines("git cat-file commit %s" % commit):
+    for log in read_pipe_lines(["git", "cat-file", "commit", commit]):
        if not foundTitle:
            if len(log) == 1:
                foundTitle = True
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/1] p4 unshelve: fix "Not a valid object name HEAD0"
  2019-05-10 15:33 ` [PATCH 1/1] p4 unshelve: fix "Not a valid object name HEAD0" Mike Mueller via GitGitGadget
@ 2019-05-15  5:25   ` Junio C Hamano
  0 siblings, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2019-05-15  5:25 UTC (permalink / raw)
  To: Mike Mueller via GitGitGadget; +Cc: git, Mike Mueller

"Mike Mueller via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Mike Mueller <mike.mueller@moodys.com>
>
> git p4 unshelve was failing with these errors on Windows:
>
> fatal: Not a valid object name HEAD0
> Command failed: git cat-file commit HEAD^0
>
> (git version 2.21.0.windows.1, python 2.7.16)
>
> The pOpen call used by git-p4 to invoke the git command can take either a
> string or an array as a first argument.  The array form is preferred
> however the extractLogMessageFromGitCommit method was using the string
> form, which makes the caller responsible for escaping the command text
> appropriately (see https://docs.python.org/2/library/subprocess.html)

Rewrite the sentence that begin with "The array form is
preferred...", as it is somewhat unreadable.  "X is preferred
because Y; however Z was using the other one" would be
understandable.

> Somewhat ironically, the carat character is the escape character in

s/carat/caret/ everywhere.

> Windows and so should be escaped (HEAD^^0).  Without the extra carat, the
> OS was passing an escaped 0 to the git command instead, and the git
> command was rejecting the invalid object name "HEAD0"
>
> The behaviour can be confirmed by typing ECHO HEAD^0 at the command-
> prompt, which emits HEAD0.
>
> The solution is simply to use the array format of passing the command to
> fOpen, which is preferred and used in other parts of this code anyway.
>
> Signed-off-by: Mike Mueller <mike.mueller@moodys.com>
> ---
>  git-p4.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 5b79920f46..0b5bfcbc5e 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):
>  
>      ## fixme: title is first line of commit, not 1st paragraph.
>      foundTitle = False
> -    for log in read_pipe_lines("git cat-file commit %s" % commit):
> +    for log in read_pipe_lines(["git", "cat-file", "commit", commit]):
>         if not foundTitle:
>             if len(log) == 1:
>                 foundTitle = True

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH v2 0/1] p4: fix "Not a valid object name HEAD0" when unshelving
  2019-05-10 15:33 [PATCH 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
  2019-05-10 15:33 ` [PATCH 1/1] p4 unshelve: fix "Not a valid object name HEAD0" Mike Mueller via GitGitGadget
@ 2019-05-28 18:15 ` Mike Mueller via GitGitGadget
  2019-05-28 18:15   ` [PATCH v2 1/1] p4 unshelve: fix "Not a valid object name HEAD0" on Windows Mike Mueller via GitGitGadget
  1 sibling, 1 reply; 7+ messages in thread
From: Mike Mueller via GitGitGadget @ 2019-05-28 18:15 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

git p4 unshelve was failing with "fatal: Not a valid object name HEAD0" and
"Command failed: git cat-file commit HEAD^0" on certain systems e.g. git
version 2.21.0.windows.1 + python 2.7.16

It seems that certain python pOpen implementations drop the ^ character when
invoked using a string instead of an array as first argument, which is what
is done by extractLogMessageFromGitCommit.

Solution is to use the array format of passing the command to fOpen, which
is preferred (see https://docs.python.org/2/library/subprocess.html) and is
used in other parts of this code anyway.

Mike Mueller (1):
  p4 unshelve: fix "Not a valid object name HEAD0" on Windows

 git-p4.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: aeb582a98374c094361cba1bd756dc6307432c42
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-183%2Fmdymike%2Fmaint-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-183/mdymike/maint-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/183

Range-diff vs v1:

 1:  fc580e902b ! 1:  5e89d1aceb p4 unshelve: fix "Not a valid object name HEAD0"
     @@ -1,8 +1,8 @@
      Author: Mike Mueller <mike.mueller@moodys.com>
      
     -    p4 unshelve: fix "Not a valid object name HEAD0"
     +    p4 unshelve: fix "Not a valid object name HEAD0" on Windows
      
     -    git p4 unshelve was failing with these errors on Windows:
     +    git p4 unshelve was failing with these errors:
      
          fatal: Not a valid object name HEAD0
          Command failed: git cat-file commit HEAD^0
     @@ -10,21 +10,19 @@
          (git version 2.21.0.windows.1, python 2.7.16)
      
          The pOpen call used by git-p4 to invoke the git command can take either a
     -    string or an array as a first argument.  The array form is preferred
     -    however the extractLogMessageFromGitCommit method was using the string
     -    form, which makes the caller responsible for escaping the command text
     -    appropriately (see https://docs.python.org/2/library/subprocess.html)
     -
     -    Somewhat ironically, the carat character is the escape character in
     -    Windows and so should be escaped (HEAD^^0).  Without the extra carat, the
     -    OS was passing an escaped 0 to the git command instead, and the git
     -    command was rejecting the invalid object name "HEAD0"
     +    string or an array as a first argument. The array form is preferred
     +    because platform-specific escaping of special characters will be
     +    handled automatically.(https://docs.python.org/2/library/subprocess.html)
     +    The extractLogMessageFromGitCommit method was, however, using the string
     +    form and so the caret (^) character in the HEAD^0 argument was not being
     +    escaped on Windows.  The caret happens to be the escape character, which
     +    is why the git command was receiving HEAD0.
      
          The behaviour can be confirmed by typing ECHO HEAD^0 at the command-
          prompt, which emits HEAD0.
      
          The solution is simply to use the array format of passing the command to
     -    fOpen, which is preferred and used in other parts of this code anyway.
     +    fOpen, which is recommended and used in other parts of this code anyway.
      
          Signed-off-by: Mike Mueller <mike.mueller@moodys.com>
      

-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH v2 1/1] p4 unshelve: fix "Not a valid object name HEAD0" on Windows
  2019-05-28 18:15 ` [PATCH v2 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
@ 2019-05-28 18:15   ` Mike Mueller via GitGitGadget
  2019-05-28 20:37     ` Junio C Hamano
  0 siblings, 1 reply; 7+ messages in thread
From: Mike Mueller via GitGitGadget @ 2019-05-28 18:15 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Mike Mueller

From: Mike Mueller <mike.mueller@moodys.com>

git p4 unshelve was failing with these errors:

fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0

(git version 2.21.0.windows.1, python 2.7.16)

The pOpen call used by git-p4 to invoke the git command can take either a
string or an array as a first argument. The array form is preferred
because platform-specific escaping of special characters will be
handled automatically.(https://docs.python.org/2/library/subprocess.html)
The extractLogMessageFromGitCommit method was, however, using the string
form and so the caret (^) character in the HEAD^0 argument was not being
escaped on Windows.  The caret happens to be the escape character, which
is why the git command was receiving HEAD0.

The behaviour can be confirmed by typing ECHO HEAD^0 at the command-
prompt, which emits HEAD0.

The solution is simply to use the array format of passing the command to
fOpen, which is recommended and used in other parts of this code anyway.

Signed-off-by: Mike Mueller <mike.mueller@moodys.com>
---
 git-p4.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-p4.py b/git-p4.py
index 5b79920f46..0b5bfcbc5e 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):
 
     ## fixme: title is first line of commit, not 1st paragraph.
     foundTitle = False
-    for log in read_pipe_lines("git cat-file commit %s" % commit):
+    for log in read_pipe_lines(["git", "cat-file", "commit", commit]):
        if not foundTitle:
            if len(log) == 1:
                foundTitle = True
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2 1/1] p4 unshelve: fix "Not a valid object name HEAD0" on Windows
  2019-05-28 18:15   ` [PATCH v2 1/1] p4 unshelve: fix "Not a valid object name HEAD0" on Windows Mike Mueller via GitGitGadget
@ 2019-05-28 20:37     ` Junio C Hamano
  2019-05-29 11:41       ` Johannes Schindelin
  0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2019-05-28 20:37 UTC (permalink / raw)
  To: Mike Mueller via GitGitGadget; +Cc: git, Mike Mueller

"Mike Mueller via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Mike Mueller <mike.mueller@moodys.com>
>
> git p4 unshelve was failing with these errors:
>
> fatal: Not a valid object name HEAD0
> Command failed: git cat-file commit HEAD^0
>
> (git version 2.21.0.windows.1, python 2.7.16)
>
> The pOpen call used by git-p4 to invoke the git command can take either a
> string or an array as a first argument. The array form is preferred
> because platform-specific escaping of special characters will be
> handled automatically.(https://docs.python.org/2/library/subprocess.html)
> The extractLogMessageFromGitCommit method was, however, using the string
> form and so the caret (^) character in the HEAD^0 argument was not being
> escaped on Windows.  The caret happens to be the escape character, which
> is why the git command was receiving HEAD0.

In the output from

    git grep 'read_pipe_lines("'

together with a few hits to harmless constant command line, we find
this line

    diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (self.diffOpts, id, id))

Would the caret we see there cause a similar problem?  It would end
up running something like

   $ git diff-tree -r -M "HEAD^" "HEAD"


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2 1/1] p4 unshelve: fix "Not a valid object name HEAD0" on Windows
  2019-05-28 20:37     ` Junio C Hamano
@ 2019-05-29 11:41       ` Johannes Schindelin
  0 siblings, 0 replies; 7+ messages in thread
From: Johannes Schindelin @ 2019-05-29 11:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Mueller via GitGitGadget, git, Mike Mueller

Hi Junio,

On Tue, 28 May 2019, Junio C Hamano wrote:

> "Mike Mueller via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Mike Mueller <mike.mueller@moodys.com>
> >
> > git p4 unshelve was failing with these errors:
> >
> > fatal: Not a valid object name HEAD0
> > Command failed: git cat-file commit HEAD^0
> >
> > (git version 2.21.0.windows.1, python 2.7.16)
> >
> > The pOpen call used by git-p4 to invoke the git command can take either a
> > string or an array as a first argument. The array form is preferred
> > because platform-specific escaping of special characters will be
> > handled automatically.(https://docs.python.org/2/library/subprocess.html)
> > The extractLogMessageFromGitCommit method was, however, using the string
> > form and so the caret (^) character in the HEAD^0 argument was not being
> > escaped on Windows.  The caret happens to be the escape character, which
> > is why the git command was receiving HEAD0.
>
> In the output from
>
>     git grep 'read_pipe_lines("'
>
> together with a few hits to harmless constant command line, we find
> this line
>
>     diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (self.diffOpts, id, id))
>
> Would the caret we see there cause a similar problem?  It would end
> up running something like
>
>    $ git diff-tree -r -M "HEAD^" "HEAD"

I think you're right!

In addition, I wonder whether we would want to replace the `^` by a `~`,
which would have the same effect, but does not need quoting in Bash nor
CMD.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-10 15:33 [PATCH 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
2019-05-10 15:33 ` [PATCH 1/1] p4 unshelve: fix "Not a valid object name HEAD0" Mike Mueller via GitGitGadget
2019-05-15  5:25   ` Junio C Hamano
2019-05-28 18:15 ` [PATCH v2 0/1] p4: fix "Not a valid object name HEAD0" when unshelving Mike Mueller via GitGitGadget
2019-05-28 18:15   ` [PATCH v2 1/1] p4 unshelve: fix "Not a valid object name HEAD0" on Windows Mike Mueller via GitGitGadget
2019-05-28 20:37     ` Junio C Hamano
2019-05-29 11:41       ` Johannes Schindelin

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox