On Mon, Feb 27, 2012 at 11:29:53AM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. -- 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