Sean, Sun, Jun 04, 2006 16:04:30 +0200:
> > 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.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html