Alex Riesen <raa.lkml@xxxxxxxxx> wrote: > On 2/6/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> 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! > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html