Re: [PATCH v3] git-rebase.txt: rewrite docu for fixup/squash (again)

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Fri, Oct 27, 2023 at 09:14:42AM -0400, Marc Branchaud wrote:
>On 2023-10-25 06:29, Oswald Buddenhagen wrote:
>> The behavior in the presence of multiple "fixup -c" is somewhat
>> questionable, as arguably it would be better to complain about it rather
>> than letting the last instance win. But for the time being we document
>> the status quo, with a note that it is not guaranteed. Note that
>> actually changing it would require --autosquash eliding the superseded
>> uses.
>
>I do not think this kind of editorializing belongs in the commit's 
>message, but this likely isn't the first commit message that expresses 
>an opinion.
>
commmit messages should elaborate alternatives considered, which 
includes ones which depend on changes that can be reasonably expected to 
possibly happen at some point.

>But I think you should remove the "but this should not be relied upon" 
>phrase.  This reads as if Git's current behaviour is undefined, which 
>most definitely is not true.
>
>Even changing this to something like "but this might change in the 
>future" is unhelpful.  Everything in Git is subject to change over a 
>long-enough time span, so the same could be said about every aspect of Git.
>
>Until the behaviour actually changes, it's perfectly fine for people to 
>use multiple "fixup -c" commands.  There's no reason to scare them off 
>of it.
>
things can't change overnight; the resistance even the most trivial 
behavior changes meet is enormous. so explicitly documenting long in 
advance that something is subject to change is basically the only way to 
get it changed at all.

specifically for this feature, there is no reason at all to rely on this 
behavior when hand-editing the todo list, and occurrences most likely 
indicate a mistake, which is why i would prefer it to be rejected.

regards