Nguyễn Thái Ngọc Duy [off-list ref] 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 <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?
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?
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.
On Tue, Dec 27, 2011 at 01:52:35PM -0800, Junio C Hamano wrote:
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?
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?
I don't personally find gc all that painful (though maybe that is
because I tend to gc myself and rarely hit the auto-gc), but I have
noticed that git-prune takes by far the most time to run. If you are
just doing an incremental pack, you might be packing only a few thousand
objects and not touching old history at all (and with many cores, the
delta compression flies by). But prune requires running "git rev-list
--objects --all", which takes something like 45 seconds for linux-2.6 on
my fast-ish laptop (and about 23 seconds for git.git).
We could perhaps cut out pruning in the auto-gc case unless there are a
lot of objects left over after the packing phase. It's not worth doing a
full prune to clean up a dozen objects[1]. It probably is if you have a
thousand objects left after packing.
-Peff
[1] Actually, it's not just having objects. You may have just exploded
unreachable objects from a pack, but they are still younger than the
2 week expiration period. Therefore trying to prune them is
pointless, because even if they are unreachable, you won't delete
them. So you really want to say "how many actual candidate objects
do we have for pruning?"
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
On Tue, Dec 27, 2011 at 01:52:35PM -0800, Junio C Hamano wrote:
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?
The main problem I've noticed with the auto gc is that git gui seems to
want to do one at a much lower threashold than the command line tools
(and far too aggressive), it seems that the logic that determines when
to do one isn't quite in agreement within all the git tools.