Re: [PATCH] git-reset: Let -q hush "locally modified" messages

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 25, 2008, 22:07 UTC
Message-ID: <7vej5hr521.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080725213853.GD13539@leksak.fem-net>

Stephan Beyer <s-beyer@gmx.net> writes:

Show 11 quoted lines

> Junio C Hamano wrote:
> ...
>> Files being "locally modified" is not and error, so I think it is in line
>> with the spirit of what -q is meant to do.
>> 
>> It is an interface change, though.
>
> Yes, as "needs update" -> "locally modified" was.
>
> However, scripts, that rely on filenames when doing -q (whyever),
> will break.

I was not worried about scripts. "reset" is a Porcelain, and it is Ok for the scripts to use it and rely on what it does (e.g. "git reset HEAD^" will move the HEAD one commit back and match your index to it), but they should not be depending on its output to be parsable. Perhaps it is Ok for them to detect if there is any change by observing if it spits out anything, but that is about it. So the earlier change to use "locall modified" does not really matter in that sense, but squelching the output altogether is a change with bigger impact. With your patch, we declare that the scripts should not assume anything about its output.

I was more worried about expectation from human users. We used to get a reminder of the paths that are different from the HEAD/index, even with the "-q" option, in the form of human-readable list of paths. Your patch changes that.

Having said all that (the only reason I said the above is not because I think this particular interface change is a big deal, but because I wanted to explain what kind of interface change I do and do _not_ care about when we talk about Porcelain), when the user explicitly gives "-q" to the command, I think it is Ok to assume that the user does not want to hear anything back. I do not see any fundamental problem with your patch in that sense.

It still is an interface change, though ;-)