On Wed, 5 Sep 2007, Junio C Hamano wrote: > Implement git gc --auto > > This implements a new option "git gc --auto". When gc.auto is > set to a positive value, and the object database has accumulated > roughly that many number of loose objects, this runs a > lightweight version of "git gc". The primary difference from > the full "git gc" is that it does not pass "-a" option to "git > repack", which means we do not try to repack _everything_, but > only repack incrementally. We still do "git prune-packed". A big part of the repack cost is the counting of objects. I don't know if --unpacked to git-pack-objects skips walking trees of a packed commit object. If no then it probably should to gain a significant speed up, or maybe a separate option should be created to actually imply this loosened semantic. > This patch does not add invocation of the "auto repacking". It > is left to key Porcelain commands that could produce tons of > loose objects to add a call to "git gc --auto" after they are > done their work. Obvious candidates are: > > git add Nope! 'git add' creates loose objects which are not yet reachable from anywhere. They won't get repacked until a commit is made. > git fetch I think that would be a much better idea to simply decrease the fetch.unpackLimit default value. > git merge > git rebase and git commit. Which resumes it to commit creating operation. Nicolas - 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
