I'm resurrecting this old thread, as we have come across a similar need and I could not tell if this has been settled. More below... On Wednesday, February 21, 2007 at 16:21:30 (-0500) Shawn O. Pearce writes: >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... As I understand this thread, it does not appear that a resolution was reached. Our company has content in our central git repository that we need to remove per a contractual obligation. I believe the content in question is limited to one sub-directory, that has existed since (or near to) the beginning of the repo, if that matters. We obviously would just like to issue a "git nuke" operation and be done with it, if that is available. Barring that, we could probably follow reasonably simple steps to purge the content and rebuild the repo. So, what options do we have at present? Bill - 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
