Quoting Carl Worth <cworth@xxxxxxxxxx>:
I don't think the warning message alone is a good fix. I think the
people who would understand the warning and appreciate that they could
then take care of repacking as convenient are the same people that
already understand the repacking concept, and are likely already
repacking occasionally, (so would likely never see the warning).
But the problematic case is the user who knows nothing of the
issue. And in that case, giving this warning isn't useful education,
it's just forcing the user to learn more and do more work. "If git
notices it has too many 'loose object' and 'git gc' would fix the
problem, then why didn't it do that itself? And what the heck is a
'loose object' anyway?"
(my 2 cents as another ordinary new git user)
Hmm, not necessarily. That a system knows what the best action is
doesn't meant that _right now_ is the best time to take that action.
One subtle difference I think between git's gc and Java/python/etc.'s
gc is that in the latter case it is, at least metaphorically, a life
and death situation - if gc isn't run, the application will run out of
memory, where as in git, it's more of a performance degradation issue,
which, sort of, can wait.
On the issue of implementation awareness, a warning message saying
something along the lines of "your repository is getting slower. You
might want to consider running 'git gc', and remember to do that from
time to time." is not much different from "your file system is getting
slower. You might want to consider running <whatever-defrag-tool>, and
remember to do that from time to time."
Neither these messages nor the actions they propose _require_ users to
learn what "repacking", "loose object", or "file fragments" are about
before they can proceed.
Cheers.
--
Jing Xue
-
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
