On Fri, Oct 27, 2023 at 09:14:42AM -0400, Marc Branchaud wrote:

On 2023-10-25 06:29, Oswald Buddenhagen wrote:

quoted

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