Re: [PATCH] fsck: do not print dangling objects by default

From: Clemens Buchacher <drizzd@aon.at>
Date: Feb 27, 2012, 21:13 UTC
Message-ID: <20120227211316.GA29081@ecki>
In-Reply-To: <7vr4xg6pn2.fsf@alter.siamese.dyndns.org>

On Mon, Feb 27, 2012 at 11:29:53AM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> >> Given that, isn't it not just sufficient but actually better to instead
> >> add a new --no-dangling option and keep the default unchanged?
> >
> > ... Of course, it is fsck, so I wonder how often clueless people are
> > really running it in the first place (i.e., it is not and should not be
> > part of most users' typical workflows). If it is simply the case that
> > they are being told to run "git fsck" by more expert users without
> > understanding what it does, then I could buy the argument that those
> > expert users could just as easily say "git fsck --no-dangling".
> 
> Yes, that was certainly part of my pros-and-cons analysis.  If you run
> "git fsck" without "--no-dangling" without reading the manual, you may
> get confused, but that is *not* the primary audience.

It is not my only concern that users might be confused. I believe the command prints a lot of useless messages, which is by itself a UI deficiency. But even worse, those numerous messages tend to hide an actual problem in a long scrollback buffer. Sometimes my scrollback buffer is not even large enough and I have to re-run fsck (which is not exactly a fast command), just so I can grep out the dangling blobs.

> People who are curious can read the manual and figure it out, and the
> need for "fsck" is much rarer these days, compared to 2005 ;-)

In my opinion, the need for fsck is much more common these days. With the alternates feature, it happens all the time that a repository breaks if one is not extremely careful.

> In that context, only large downsides of potentially breaking and having
> to adjust existing scripts remains without much upsides, if we were to
> switch the default.

There is something wrong with weighting a UI improvement against convenient use in scripts. If that were the issue, then we should add a plumbing version for all commands, like we do for git status --porcelain. Otherwise we can never change anything any more.