On Tue, Aug 23, 2011 at 3:27 AM, Pete Wyckoff <pw@xxxxxxxx> wrote: > I think I understand the problem now, and have a small test case > to see what's going wrong. Your solution is definitely > sub-optimal. :) Is there anything that can be done with > --import-marks and --export-marks? Don't know if you agree, but I think it would be better to keep git-p4 from storing extra files in the filesystem. And, as far as I understood, these two options require extra files. But I don't think marks would help us that much. We already have something similar: the changelist number in the commit log. The big problem is that P4 does not store a pointer to the previous changelist. > Could you guess at the branch point using p4? I.e. for each file > in the new branch, grab the change that caused its most recent > revision (the #xx part). Pick the max of those changes. In git, > find the commit whith "change = ..." that you just discovered. > That's the parent. Yes, I think this would work. Nevertheless, I would prefer not to do so much pooling on the P4 server because when we're in a remote location in regards to the P4 proxy server this kind of command becomes rather slow. And if the branch has many files this may become cumbersome. > Even this won't be perfect, and I'm not even sure if it's less > icky than diff-tree. >From what I can see, the two possible solutions would be: a) Running a "filelog" on all files. This may become slower when the branch has lots of files. There's also the problem in needing to contact the P4 proxy server every time. b) Using diff-tree. This will be slower if the original changelist is very far from the latest one, but has the advantage of being run locally. It has the disadvantage of not having an apparent compatibility with fast-import. In my personal point of view, diff-tree solution still looks better, if it weren't for the fast-import issue. Now if we could just figure out how to overcome this issue... -- Vitor Antunes -- To unsubscribe from this list: 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