git-p4 submit fails with "Not a valid object name HEAD~261"

Question

I've got a git repository that I'd like to mirror to a Perforce repository. I've downloaded the git-p4 script (the more recent version that doesn't give deprecation warnings), and have been working with that. I've figured out how to pull changes from Perforce, but I'm getting an error when I try to sync changes from the git repo back. Here's what I've done so far:

git clone [email protected]:asdf/qwerty.git
git-p4 sync //depot/path/to/querty
git merge remotes/p4/master     (there was a single README file...)

So, I've copied the origin to a clean, new director, got a lovely looking merged tree of files, and git status shows I'm up-to-date. But:

> git-p4 submit
fatal: Not a valid object name HEAD~261
Command failed: git cat-file commit HEAD~261

This thread on the git mailing list seems to be relevant, but I can't figure out what they're doing with all the A, B, and Cs. Could someone please clarify what "Not a valid object name" means, and what I can do to fix the problem? All I want to do is to periodically snapshot the origin/master into Perforce; a full history is not required. Thanks.

Answer 1

9 years later, that issue might be gone with Git 2.23 (Q3 2019)

See commit c3f2358 (28 May 2019) by Mike Mueller (mdymike).
^{(Merged by Junio C Hamano -- gitster -- in commit add59c4, 17 Jun 2019)}

p4 unshelve: fix "Not a valid object name HEAD0" 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

(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.