views:

227

answers:

1

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.

A: 
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
VonC
I'm sorry, I don't understand. Could you please try again? Thanks.
Harlan
@Harlan: I have emphasized the role of repo `C`. I do not fully understand the *exact* cause of this issue, but I just wanted to illustrate the workaround proposed in the thread you mention.
VonC
Also, the steps in that mailing list thread don't seem to have a separate git origin repo, which I have, and seem to have B and C on separate machines, which is confusing to me.
Harlan
@Harlan: B and C are on the same machine. As for the workaround, it is indeed after a `git-p4 clone`, not a `git clone`. Still, the idea remain: one initial import in a local git repo, made bare after that (B), and all the work done from C (cloned from B)
VonC