Alex Riesen <raa.lkml@gmail.com> wrote:
quoted text
> On 2/6/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >I'm mainly worried about breaking compliation on odd architectures.
> >gfi builds, runs and has been used for production level imports
> >on Mac OS X, Linux and Dragonfly BSD, using both 32 bit and 64 bit
> >architectures, but some of Git's other targets (e.g. AIX) haven't
> >seen any testing.
> 
> Compilation errors are the simplest to fix, just send it in.

True.

But it really is annoying when you download the latest-and-greatest
release of a package only to find out it doesn't compile on your
OS of choice, and even worse when you find out it is because of
new code that you will never use which was added in just before
the release went final!

quoted text
> I have to import lots of data from perforce spaghetti, so I'm very
> likely to try it out.

I can't help you with spaghetti, but the Qt folks did make their
Perforce importer available.  Chris Lee put it in the fast-export
project on repo.or.cz.  Its a relatively short Python program.
Might help you get started.

They created annotated tags (with no message) for every p4 changeset.
I think its just because they didn't realize you can use (abuse?) the
`reset` command in gfi to create lightweight tags instead.


I actually implemented a "data <path" command in gfi to tell gfi
to load data from a file, for this type of case where the foreign
system has dropped the files in your working directory and you just
want Git to read them.

But there's no synchronization between gfi and the frontend (aside
from the pipe buffer throttling the frontend), so there is no way
for the frontend to know that gfi has finished a batch of files
and its safe to ask p4 for the next revision.

So I threw it away.  It was only a 10 line patch anyway.  :)

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html