Re: [PATCH] A Perforce importer for git.

From: Alex Riesen <fork0@t-online.de>
Date: Jun 5, 2006, 21:00 UTC
Message-ID: <20060605210018.GA22650@steel.home>
In-Reply-To: <20060604100430.cb2789dd.seanlkml@sympatico.ca>

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

Show 9 quoted lines

> > 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.

Show 6 quoted lines

> 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.