Russ Dill <Russ.Dill@xxxxxxxxx> wrote: > > Ok, how about doing something like this? > > git add? merge? rebase? No, I have a sneakier place to invoke gc. > > Whenever $EDITOR gets invoked. Heck, whenever git is waiting for any user input, > do some gc in the background, it'd just have to be incremental so that we could > pick up where we left off. Heh. That is a really good idea. I've been thinking about doing some automatic generational style GC type repacking controls in git-gui, and doing them when git-gui is sitting idle and has not been used in the past couple of minutes. This is along the same vein of thought. I like it. Often it takes me a while to come up with a good commit message even if I am using command line commit. But git-rebase/git-am can cause a huge number of objects to be created, especially if you are pushing a large stack of patches around. So it may still be a good idea to trigger `gc --auto` at the end of those operations. > Similarly, you could mix it in with git pull/push so that while we are waiting > on the network, we can do some packing. Here's a better thought: If we are pushing somewhere, and the push size is "large-ish" and we aren't pushing a thin pack (its currently considered not nice to the remote end so it doesn't happen by default) and the objects we are packing are mostly all loose maybe we should also save a copy of that packfile locally, then prune *only* those loose objects back. Not every git user pushes their work. But many do. And those that push usually will do so in bursts, are already expecting to wait for the network latency, and usually are pushing the majority of the things that are loose. Such users will probably never see the `gc --auto` trip in places like commit/am/merge as they would already be clearing their ODB with the push. -- 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
