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 git@github.com: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.
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.
fatal: Not a valid object name
should mean that somehow the remote's HEAD points to an incorrect reference.
In other word, when you do a P4 import in a git repo, there is no way to submit from that git repo to P4, because of an incorrect SHA1. Why? I don't know.
That is why, in the thread you mention, the user:
- clone the P4 repo into B with
--import-local ("Import into refs/heads/, not refs/remotes"),
- make B (the Git clone of the p4 repo) a bare repo (so you won't ever work in it, since its working tree is empty)
fix the HEAD of B to reference the p4 master branch imported in B
clone B into C, a non-bare repo (its working tree is not empty, you can work in it)
B was only there for the initial import.
The rest of the work is done in C (which has no issue of incorrect SHA1) with:
git-p4 sync (to declare in C remotes/p4/master in addition to remotes/origin/*)git-p4 submit
