Skip to content

p4: fix "Not a valid object name HEAD0" when unshelving #183

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

p4: fix "Not a valid object name HEAD0" when unshelving #183

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion git-p4.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -737,7 +737,7 @@ def extractLogMessageFromGitCommit(commit):

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Mike Mueller via GitGitGadget" <[email protected]> writes:

> From: Mike Mueller <[email protected]>
>
> 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 <[email protected]>
> ---
>  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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Mike Mueller via GitGitGadget" <[email protected]> writes:

> From: Mike Mueller <[email protected]>
>
> 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"

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio,

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

> "Mike Mueller via GitGitGadget" <[email protected]> writes:
>
> > From: Mike Mueller <[email protected]>
> >
> > 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 eithe=
r 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.ht=
ml)
> > The extractLogMessageFromGitCommit method was, however, using the stri=
ng
> > form and so the caret (^) character in the HEAD^0 argument was not bei=
ng
> > escaped on Windows.  The caret happens to be the escape character, whi=
ch
> > 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 =3D read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (sel=
f.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

## 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
Expand Down