Quoting Carl Worth <cworth@cworth.org>:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html