On 2/19/24 22:44, Junio C Hamano wrote:
Ricardo C <rpc01234@xxxxxxxxx> writes:
This is an issue I hadn't considered, and I'm not sure whether it can
even be fixed. In some sense, the entire point of this patch is to
allow the user to break that promise in their configuration. However,
I'm not sure how big of a problem this is, as it is entirely opt-in
(default behavior should be the same as current behavior),
Correct.
and tools
can be altered to pass `--no-keep-index --no-include-untracked` if
they wish to force the current behavior.
This is not.
People expect a bit better from Git, and such a callous disregard to
backward compatibility that breaks other people's tools and scripts
is a non-starter.
Users of such tools, whether they were written by themselves or
other people, do *not* want them to break only because they want to
use a shiny new feature that is advertised in a new version of Git.
The point of packaging a solution, the reason why they wroute such a
tool or script that happens to use "git stash" as an ingredient and
depends on the current behaviour of "git stash", is so that they do
not need to remember they even used "git stash" as a small part of
their solution. And of course they do not want to remember that
they rely on how "git stash" behaves in such a solution. They do
not even want to bother complaining loudly when such a change is
proposed before it hits a release and hurt them. Saying "nobody
complained when these configuration variables were proposed" does
not help anybody later, after we already hurt them.
That makes sense. Do you have any ideas on how to address this? It feels to me
like providing this config option is fundamentally incompatible with requiring
backwards-compatible behavior regardless of configuration.
Ricardo
