summaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorShawn O. Pearce <spearce@spearce.org>2007-04-20 15:23:45 (GMT)
committerShawn O. Pearce <spearce@spearce.org>2007-04-20 15:23:45 (GMT)
commita5c1780a0355a71b9fb70f1f1977ce726ee5b8d8 (patch)
tree0b421231d806b5b313033f98daa87904e6e8e637 /contrib
parent744747ef1d75c85fb3a1785cb08d36497128d3d3 (diff)
downloadgit-a5c1780a0355a71b9fb70f1f1977ce726ee5b8d8.zip
git-a5c1780a0355a71b9fb70f1f1977ce726ee5b8d8.tar.gz
git-a5c1780a0355a71b9fb70f1f1977ce726ee5b8d8.tar.bz2
Don't repack existing objects in fast-import
Some users of fast-import have been trying to use it to rewrite commits and trees, an activity where the all of the relevant blobs are already available from the existing packfiles. In such a case we don't want to repack a blob, even if the frontend application has supplied us the raw data rather than a mark or a SHA-1 name. I'm intentionally only checking the packfiles that existed when fast-import started and am always ignoring all loose object files. We ignore loose objects because fast-import tends to operate on a very large number of objects in a very short timespan, and it is usually creating new objects, not reusing existing ones. In such a situtation the majority of the objects will not be found in the existing packfiles, nor will they be loose object files. If the frontend application really wants us to look at loose object files, then they can just repack the repository before running fast-import. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Diffstat (limited to 'contrib')
0 files changed, 0 insertions, 0 deletions