Some quick answers before I go to sleep. Johannes Sixt wrote: > What is the special new thing here? That "" means 'empty string' == 'tree > at the root'? If so: Yes. > 1. Then this is the missing piece in the justification. Then I could buy > that the observed speed-up is due to the reuse of an existing tree object > (which avoids parsing it and re-constructing it from its pieces because > fast-imports syntax didn't allow it otherwise). But it has nothing to do > with new loose objects (the re-constructed object would be identical to an > existing one). If I remember correctly: Version 1 of the script was similar to filter-branch and used "git read-tree", "git write-tree", and "git commit-tree" (or something equivalent). Reconstructing the trees seemed to be a significant overhead, leading to: Version 2, which just called "git commit-tree" (or equivalent) repeatedly. What this patch allows is Version 3, which is a bit over 20% faster than version 2 and uses fast-import to write the new commits directly to pack. That speed-up could be due to avoiding the repeated fork() + exec() + git startup cost, or avoiding loose objects, or any number of other things. Without this patch, one could write Theoretical version 1', which uses cat-file --batch to unpack each tree and uses fast-import to write commits with the same (recreated) tree directly to pack. But that would be kind of insane. > 2. Without this patch, would this syntax create a tree object with a name > consisting of two double-quotes in the root? Or would it be a syntax > error? Syntax error. > How would one construct such an entry with this patch? M 040000 <tree id> "\"\"" Thanks again. -- 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