Re: [PATCH] A Perforce importer for git.

Sean, Sun, Jun 04, 2006 16:04:30 +0200:

quoted

I'm rather looking for a ability to manage a single branch where
import "sync" events appear as a merge of changes to the files
involved in the sync. I just haven't figured out yet how to "break" a
Perforce change into changes to single files and import that broken up
commit into git as a merge.

Ahh, so what you're really asking is for a way to maintain the perforce
merge history within git.  Whereas the current p4import script just
shows a linear history without any merges.

I assume that by "perforce merge" you understand the set of revisions
in the working directory. That's what you get in a typical corporate
environment with hundreds libraries and source files somehow stitched
together in a hope it'd work. It does, surprisingly often. There is
also another "merge" in perforce workflow - plain text merge of many
files, done manually in working directory and checked in afterwards.
I believe it wouldn't be possible to get a history of this merge,
because there is just no information about the merge anywhere.

The problem is that Perforce doesn't merge at the commit level.  It
allows changes from other branches to be pulled one file at a time and
from any rev level.

Right. Awkward.

Now, even if you break those changes into one git commit per file per
revision level (yuck!), you still couldn't use them to record Perforce
merges.  Git would still merge the entire history of such commits from
the other branch whenever you tried to merge just one.

I think it's worse: you can't merge (as in git) anything because of
that salad from local (working) and remote (p4 server-side) pathnames.

AFAICS, the best you could do would be to create cherry-picks, plucking
just the commits from the other branch you want.  However at that point
you're not getting a git merge anyway and it doesn't seem to be any
benefit beyond what the importer already does.  Well, the importer
_could_ make a comment in the commit message describing where each
file change originated (ie. from which branch/rev).  Would that help?

Don't think so, even if this is surely better detailed this way. I
still wont have the ability to merge branches. Maybe if every change
to every file gets it own commit one can use that information to
either cherry-pick the changes or fix the pathnames and apply that
patch? And a P4 change could be represented as a git-merge.

Like this:

P4:
    Change 213412
    a/foo.c #3
    b/bar.c #6

Git:
     +--commit abcdef ----+
     |  a/foo.c +3 lines  |
base-+                    commit deffff (merge, represents Change 213412)
     |  commit abcccd     |
     +--b/bar.c -3 lines -+

Now I can cherry-pick (or just copy) commit "abcdef" or commit
"abcccd", and still can find out what that "Change 213412" was all
about.