10

I'm runnining on Windows, with the windows p4 client, and git installed via Cygwin. The p4 client advertises how its syntax is regular across platforms and all that, so that should be hunky-dory.

So when I go to git-p4 clone --verbose //depot/path/to/source, it lists out all the files in the repository as though they were being checked out, then dies saying

Exception: fast-import failed: warning: Not updating refs/remotes/p4/master (new tip cd601b92da8625c90af05685e450e55b6d19c9e9 does not contain 3a512c9408e3cbeef 94c78dfd7115f81e4a6fd0d)

and concludes with a big block of "git-fast-import statistics". Looking at the error: new tip? Huh? What needs to contain it?

What I'm left with is a .git repo that's a couple of megs (much, much smaller than the full source tree would be). Any ideas?

bsberry
  • 954
  • 1
  • 10
  • 24

5 Answers5

3

Do you get "Ignoring revision XYZ as it would produce an empty commit" for the very first CL to be imported?

If so, you're hitting a bug in git-p4.py where it clears the "initialParent" setting (necessary so that git fast-import can join the new commits up to the previous import) before it actually commits anything. The new stream of imported files are therefore left unconnected to the old.

I'm currently working around this by using --changesfile and working out explicitly which CL's need to be imported.

IanH
  • 51
  • 1
  • 5
    You can also workaround the issue by using `git config git-p4.keepEmptyCommits true` if you don't mind having some commits with no changes in your git tree. – Eric Feb 11 '18 at 21:28
  • @Anton, I dealt with this issue for about 3 or 4 months and even had my own answer to this question (now deleted) that involved rolling back the p4/master commit and rebasing again. Then I re-read this answer and came to this new solution which so far hasn't run into any problems. Hopefully git-p4 will be fixed in the future so we don't need the extra empty commits but this is a good trade-off to avoid it breaking often :-) – Eric Feb 13 '18 at 19:36
  • This answer speaks to my root cause for encountering the error. Thank you! I work on a small piece of a very large depot (my company is said to be one of p4's largest corporate users). It is common for the first changelist of a `p4 sync` range not to intersect the subset of files that are mirrored into my git repo, which was populated using --use-client-spec. – JeffJ Feb 08 '19 at 13:36
  • This remains a problem today, even when using the mingw version of git (Git Bash Shell for Windows). Enabling `keepEmptyCommits` remains a viable workaround for both mingw and cygwin versions of git. I'm unclear if it is the first or last p4 changelist, when "empty", that triggers the bug. I suspect it's the last changelist in the range, or maybe when the entire range is empty. – JeffJ Apr 29 '21 at 19:50
3

I've had a similar problem and can usually be traced to the casing in paths, branch names, etc. Not sure about P4 but ensure that you don't have a Master branch - it should be master. Follow the same regiment across the board. Also, avoid directory and file names with spaces in them. A lot of git-centric tooling does not like that. Gitolite is one example. It will not allow a repository that has a space in it.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 1
    You had it right: moving to a folder with no spaces in the path name fixed it. – bsberry Nov 02 '10 at 14:32
  • @Hober what do you mean without spaces? in your question i can't see any spaces in the command. – Giedrius Feb 07 '18 at 20:49
  • @Giedrius I mean file system paths with spaces in them, like "C:\Program Files\foo". A good way to fix this would be to use your C:\Users directory, or make your own C:\dev directory for development purposes. Sorry for the slow answer. – bsberry Jun 08 '18 at 21:00
2

Similar to the accepted answer, I had this same problem when trying to sync to a git branch in the form:

git p4 sync --branch=feature/f1 //depot/path/to/code

The / in the branch name appeared to cause the same cryptic fast-import failed warning. Unfortunately git-p4 doesn't seem to support standard git-flow branch names.

Changing to a branch like this worked:

git p4 sync --branch=f1 //depot/path/to/code
NickU
  • 21
  • 1
2

I also encountered the "new tip x does not contain y" error running fast-import.

In my case, this was caused by an unrelated preexisting commit in the master branch of the repo I was attempting to import into. I had initialized the repo with the GitHub client which added an initial commit (to add a .gitignore file). The fast-import tool presumably could not reconcile the imported commits with the current state of the branch since the GitHub tool's commit had no relationship with the commits being imported.

The solution for me was to instead initialize an empty repo with "git init" and then run fast-import.

Alan
  • 1,148
  • 1
  • 9
  • 17
  • I ran into the same problem when I tried to initialize the repository with a `.gitattributes` file to set binary file patterns. I want this commit to be the very first in the repository to make sure that the definitions apply to all tagged versions. – OK. Feb 12 '20 at 10:21
1

I had similar problems. What worked for me was updating the git-p4 python code. You can take a look at the commit here, but hopefully it will be pulled up soon.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
Andrew
  • 11
  • 2