Re: [PATCH] gc --auto: warn garbage collection happens soon

2011/12/28 Junio C Hamano [off-list ref]:

Nguyễn Thái Ngọc Duy  [off-list ref] writes:

quoted

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 <redacted>

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