Home/ Questions/Q 3930574
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T23:16:11+00:00

I have the task of migrating my team & source from git to Perforce,

  • 0

I have the task of migrating my team & source from git to Perforce, and I’m looking for ideas on how to move the git history into p4.

I would be happy moving master branch only. However, even that is proving problematic.

I’m using the wonderful git-p4 tool. I create an destination area in my p4 workspace, and use git p4 clone //depot/StuffFromGit to start tracking it in git-p4. I graft all my git repository’s changes into the git-p4 clone. I can then git p4 submit and be done, all the changes are pushed to p4.

It works great when the git history looks like this, nice and linear:

A---B---C---D

The problem comes with multiple people working on the project. Even though they are working on master, that still creates branches that split and merge. Still, git-p4 bravely handles this:

A---B---C---E
     \--D--/

git p4 traverses OK, committing ABCDE in order (or ABDCE, either person’s history first).

The problem comes when, for example, C and D both change the same file, and E is a real-honest-to-goodness merge. git p4 rebase fails here; it’ll rewind the commits, but during playback it’ll apply C first, then attempt D and find a conflict. It’ll then stop, asking me to merge. Well, E contains the merge but it’s asking me to hand-merge! ‘git p4 submit’ will fail in a similar way, only now it’s p4 rejecting the pre-merge change.

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging main.cpp
CONFLICT (content): Merge conflict in main.cpp
Failed to merge in the changes.
Patch failed at 0005 Changing main

So now I’m stuck. Is there a way to sanitize the git history or to get git-p4 to understand it? It’s frustrating as the merges are there.

Thoughts I’ve had:

  • Use git filter-branch to remove all mention of conflicting files. I’d get the history comments across, though missing many file changes. With about 3000 commits in the history, I would wind up removing all of the key (busy) files’ history. At the end of the filtered-files import, I’d add the missing files back by doing a final commit of the HEAD.
  • Dump the history, do a single p4 commit of the HEAD (simple but sad).
  • Not move to p4: I’ve worked that idea for as long as possible.

None of which are really great. Any ideas on how to git ‘gt p4 rebase’ or ‘git p4 submit’ to work?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The option of “just throw away the old history” is not as bad as it sounds: you can just keep your git repo alongside it forever, in case anyone needs to dig through the old stuff. Unfortunately, there is just no way to represent git’s complex view of history in old-style linear systems like svn and p4.

    The main reason to look back into old history is for things like ‘git annotate’ (I assume p4 has a similar tool). If that’s all you want, then maybe what you really want to do is squash all your merge commits down to only one of their parents (so they look like a single commit instead of a merge). That’s more like what svn and p4 would have recorded in their own history model, where merges just look like a single commit in the linear stream. You can probably do this with git-filter-branch or the like. Of course, this would lose all the history that happened on sub-branches… but p4 users are used to not having that information.

    • 0