2011/12/28 Junio C Hamano <gitster@xxxxxxxxx>: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> This gives users a chance to run gc explicitly elsewhere if they do not >> want gc to run suddenly in current terminal. >> >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> > > As I am still in a cheerly holiday mood, let's be a bit philosophical, > step back a bit and think. > > After this patch gets applied, will the users start feeling bothered by > repeated "you will soon see auto-gc" messages and will want "you will soon > start seeing the you will soon see auto-gc messages" warnings? They should not for most of the time, given the default settings is warnings at 90% limits. If they do feel bothered, they could turn it off or just run "gc". > And if the answer to that tongue-in-cheek question is no, what is the > reason why the users will not find the messages disturbing, while loathing > the auto-gc? > > I suspect that is because auto-gc takes long time, making the user wait, > compared to the new message that may be noisy but quick. Perhaps the real > cure for the disease is not to add the message but to make an auto-gc less > painful, no? It's something with expected run time of a command. When I'm about to run "commit", I know the command is fast and I expect the shell prompt soon. When I run "fetch", I know it may take a bit (or a lot) of time and I will be ready to make myself a cup of coffee while it's running. auto-gc is an unknown factor and may break my expectations. I would not mind if auto-gc is extremely fast, e.g. a couple of seconds maximum. But gc time seems to be proportional to repository size. > What are the things we could do to make auto-gc less painful? > > Are we doing something that is not necessary in auto-gc that takes time > but that we can live without doing? > > It may be a better cure for the disease to force a full gc after > operations that we know the users already know to take long time (e.g. a > clone, a large fetch), so that the next auto-gc do not have to do much > work. git works best when everything is in one pack. So while we may be able to skip stuff and make auto-gc fast the first few times, eventually we need to do something like "git repack -ad" as part of auto-gc. I don't see any way to make that part complete in a few secs regardless repo size (unless packv4 comes in time and speeds up revlist significantly). So the pain will be there in the end, it's just delayed. There's another possibility (but not sure if it's feasible): to make auto-gc use up to certain amount of time. If it runs out of allocated time, it needs to save its state somewhere, somehow and resumes in next auto-gc. -- Duy -- 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