Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > The probnlem there is that most conversion scripts that use > "write_sha1_file()" will want to *read* that file later. If > git-fast-import hasn't generated the pack yet (because it's still waiting > for more data), that will not work at all. Yes, indeed... > So then you basically force the conversion script to keep remembering all > the old object data (using something like pretend_sha1_file), or you limit > it to things that just always re-write the whole object and never need any > old object references that they might have written. > > A lot of conversions tend to be incremental, ie they will depend on the > data they converted previously. Which is why I was actually thinking of flipping this on its head. Libify git-apply and embed that into fast-import, then one of the native input formats might just be an mbox, or something close enough that a simple C/perl/sed prefilter could make an mbox into the input. fast-import can (and does if necessary) go back to access the packfile it is writing. It has the index data held in memory and uses only OBJ_OFS_REF so that sha1_file.c can unpack deltas just fine, even though we lack an index file and have not completely checksummed the pack itself. So although no other Git process can use the packfile, it is usuable from within fast-import... -- 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