From: Ricardo C Date: Tue, 20 Feb 2024 03:59:53 GMT Subject: Re: [PATCH] builtin/stash: configs keepIndex, includeUntracked Message-ID: <31135b8a-af7a-4d73-b3b3-d91ea8d3d5fd@gmail.com> In-Reply-To: On 2/19/24 22:44, Junio C Hamano wrote: > Ricardo C 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