Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > Anyway, git-convert-objects does kind of give you a starting point. It > should be fixed to use "git-fast-import" or repack once in a while (so > that it doesn't leave tons and tons of unpacked objects), and it should be > fixed to fix up any commit messages that mention SHA1's that it has > already converted to something else, but it seems to still work. It would > not be impossible at all to extend the tree-rewriting logic to remove some > file or a particular SHA1 object you want to replace. One idea Junio and I kicked around on #git a short while ago was to arrange for a pipe between the current Git process and git-fast-import, where the pipe was used from within write_sha1_file() rather than creating the loose object. This way an existing process like git-apply or git-convert-objects could easily spew hundreds of thousands of objects without needing to worry about repacking in the middle; nor would we need to worry about the complexity of trying to disentagle the multiobject packing parts of fast-import into some sort of library. Obviously this is only a good idea if we are going to be making enough objects to warrant using a packfile; small 10-20 bursts of objects from a git-apply doesn't really justify a packfile. But applying 100s of patches in a row might, if we could keep them all fed through the same git-fast-import backend (and thus into the same packfile). -- 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