Re: State of Perforce importing.

David Brown wrote:

On Tue, Sep 18, 2007 at 06:53:45PM +0100, Reece Dunn wrote:

quoted

The main issues with using client workspaces is that they require you
to use `p4 sync`, whereas git-p4 uses `p4 print` and that they may
change as the repository changes, but Perforce does not track these
changes.

Unfortunately, we have one project that heavily abuses P4 client specs.
For every release, someone creates a >900 line client spec and labels the
files in it.  Those are the versions that need to get checked in, and
without rewriting much of what P4 does, I'm going to have to let P4 do the
syncing and checking out.

If you can get a hold of the "checkpoint" and "journal" files, you could
probably throw the client spec data into a few Pg tables, chuck a couple
of constraints on it to confirm that it works the way you thought, and
then get the information on what's where using a SQL query.  The file
images themselves can come from wherever, it doesn't really matter
because there are MD5 hashes in the data tables you can use to confirm
you got the right file.

I haven't looked at importing the client spec because it's not important
for the project I'm importing.  But I'd be happy to provide pointers.

quoted

I would not do that. It is a good idea to keep the original log
messages, even if it does make for an uninformative shortlog. Look at
some of the CVS/SVN imported logs!

I think what I want then is something to filter between 'git log' and 'git
shortlog' that would find a summary line in the commit message and copy it
to the top.  It wouldn't change the history, but clean it up for shortlog's
purpose.

Sounds like a job for a templating git-log porcelain.

Sam.