Re: [PATCH] Update "gc" behavior in commit, merge, am, rebase and index-pack
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- May 14, 2012, 09:09 UTC
- Message-ID
- <CACsJy8DxoRHYnBvJn7P9dS1A0Y88Bm0ur1meWCUBp09UEfuOgg@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.2.02.1205121326380.21030@xanadu.home>
On Sun, May 13, 2012 at 12:36 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
Show 23 quoted lines
> On Sat, 12 May 2012, Nguyễn Thái Ngọc Duy wrote: > >> A few attempts have been made in the past to change 'gc --auto' [1] >> [2]. This is another such attempt. >> >> Commit d4bb43e (Invoke "git gc --auto" from commit, merge, am and >> rebase. - 2007-09-05) used the rule to put "gc --auto" is "where >> update-ref occurs". I would argue that this is not a good condition to >> run gc, because (at least current) gc is slow. We encourage commit >> often and rebase to make all patches in good shape and this workflow >> should not be interrupted/slowed down by random "gc --auto". >> >> Instead, we could just inform users that "gc" should be run soon in >> commonly used commands (this patch also reinstates "gc" check in >> commit, which was lost at the sh->C conversion). [1] and [2] can annoy >> users constantly with warnings. This patch shows the warning at most >> once a day. > > I agree with this. However don't bother making this once a day. There > is no harm in warning every time. Referring to the man page as git > --auto does when it actually meets its treshold wouldn't be a bad thing > either as incidentally that would contain the info to get rid of the > warning.
I'm good with always warning too. The moment it shows up, I can just open another terminal for "gc". Though (I guess) a new user in the middle of the work may not want to do that as they fear "gc" may interfere their work. Then the warning becomes a constant annoyance (and maybe forgotten after they're used to seeing the warning).
If everybody's good with always warning, I'll make a new patch.
-- Duy