Re: [PATCH] pathspec: prevent empty strings as pathspecs

[Junio C Hamano <gitster@pobox.com>]

David Turner <novalis@novalis.org> writes:

> The help for rev-parse --show-prefix says:
> "When the command is invoked from a subdirectory, show the path of
> the current directory relative to the top-level directory."
>
> This doesn't say what it does when invoked at the top-level.  Maybe we
> should just change it to output "./", which would make such scripts
> work?  It would not necessarily fix all possible scripts, but it would
> fix these.  It seem odd to insist on preserving this undocumented
> behavior of git add/rm.

For two obvious reasons, you do not want to go there.

As you seem to understand in the above, "--show-prefix" was given
merely as an example, so updating its behaviour would not change the
fundamental problem with the patch under discussion at all.  It will
break scripts that knew, documented or not, that pathspec match is a
prefix substring match that honors directory boundary and an empty
string is defined long time ago to match any path and it does not
matter if that definition was made by mistake.

Also, if you change "--show-prefix" output, documented or not, that
will break other scripts that knew that checking it against an empty
string is a valid way to check if you are already at the top level
of the working tree.  And I highly suspect that such a change is
much harder to advertise and warn existing scripts, compared to the
change proposed by the patch under discussion.  The output routine
in show-prefix knows what it is giving to the caller, but does not
know how the caller uses it and what for.  Compared to that, ...

>> At least you would need two-step process to introduce a change like
>> this to warn the people whose tools and workflows you are breaking.
>> That is, (1) in one release, you add code to only detect the case
>> you will be changing the behaviour in a later version and give
>> warning messages, and (2) in another release that is several release
>> cycles later, stop warning and actually change the behaviour.

... is a lot easier transition (again, assuming that this change is
worth doing in the first place).