From: Junio C Hamano Date: Tue, 16 Sep 2025 16:03:39 GMT Subject: Re: [PATCH v2 1/2] add -p: mark split hunks as undecided Message-ID: In-Reply-To: Phillip Wood writes: > To me, the current behavior is strange enough to be considered a bug > but when we discussed this before you were not so sure and said [1] > > Given our user base has grown quite a bit over the years, it > almost is a given that any change to existing behaviour is a > regression to somebody. Certainly a safe material for Git 3.0 > but I do not know if it is safe enough for 2.50 for example. > The strategy to leave it longer in 'next' did not work well > to catch potential issues for another topic during this cycle, > but we could try it out again. > > So I re-rolled using WITH_BREAKING_CHANGES. If you're happy just to > change the behavior unconditionally I can go back to V1 I am *NOT* happy with breaking changes. Either you cut off those who you do not believe exist because the behaviour is so strange and useless (i.e. immediate "this is a bugfix, there is no mechanism to keep the broken behaviour even for a short period"), which is much better than that from my eyes if I were to be convinced that the old behaviour is nonsense, or you support them with configuration without any future deprecation, which is also fine by me. The breaking changes mechanism is to be used only when we are convinced that the old way is nonsense, we are fairly sure that no sane user is using it, and we have concensus that the old way MUST be abandoned and any existing users MUST be retrained to use the new ways, and only to buy/give some time to these users that needs retraining. Have we got that firm sense in the community that the old behaviour qualifies for breaking change mechanism? I don't, at least not yet. >> On the other hand, assuming it is not a bugfix but introducing a >> different behaviour, where both the original and the new ones are >> useful depending on the situation, wouldn't it be better to give >> users choices at runtime instead, with a configuration variable at >> least, but possibly with a interactive command to choose which >> behaviour is used on demand? > > I'm not really convinced the current behavior is that useful and it is > such an esoteric use of 'add -p' that I'm not sure it makes sense to > add a config setting for it. If so, let's break it first and see if anybody screams. Touching the breaking changes mechanism is way too early before doing that, I think.