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.
