David Turner <novalis@xxxxxxxxxxx> 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). -- 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