Re: 'git reset -- NonExistingFile' succeeds

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 6, 2019, 01:51 UTC
Message-ID: <xmqq36f1ydps.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <df35c20c-669e-35a1-9b2c-22940637b560@syntevo.com>

Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> writes:

Show 11 quoted lines

> On 02.11.2019 5:49, Junio C Hamano wrote:
>> It's sort of expected ;-)
>
> Didn't expect such a detailed reply, thanks!
>
> Not really a problem for me, just I was surprised and thought that I'd
> ask about it.
>
> I came across this issue when writing a test for 'git reset'. I'll
> simply change the test to verify the repository state instead of
> expecting 'git reset' to fail.

As I said, it is expected that Git is not perfect and there would be many little corners like this that can use improvements. IOW, it is not unexpected that "git reset -- NoSuchFile" does not raise an error, but that does not make it a bad idea to at least think about teaching it to do so. There _might_ be fallouts, though; there may be scripts by people that rely on 'git reset -- "$variable"' with some random pathspec in a $variable to quietly become no-op when no paths match (in which case, we'd have to mimic ls-files and add a "--error-unmatch" option, perhaps).