There was some discussion [1] about making that the default and renaming
it - was that overlooked? If not it would be helpful to comment on those
discussions to explain why you don't think it is a good idea.

Not overlooked, but I side-stepped it because the discussion died
down, and yes I don't agree that it needs to be the default. I could
have mentioned my thinking in the cover letter.

quoted

    now builds the same editor template git rebase -i shows
    for a squash (a combination of N commits banner with each folded message
    under its own header) and follows autosquash for markers: a fixup!
    message falls out (commented under a will be skipped header), while a
    squash! or amend! keeps its body with only the marker subject commented
    so its remark can be reworded in. Only the message text is affected,
    every commit's changes are always folded in.

Rebase re-orders commits so that fixups immediately follow their target
- do you do that here? I think that is very relevant because here we may
be dealing with several different commits each being targeted by a set
of fixups and presenting them mixed together will be confusing.

No, I'm not doing that now, but I can take a look at that.

I think it should allow squashing a bunch of fixups together though. I
thought there was a plan [3] to refuse to squash a fixup unless the
range included its target.

I attempted this with reject_fixupish_oldest(), assuming only the
first commit needs to be checked as not being a fixup/squash/amend.

But now I realize that maybe we need to check all of the commits, and
also check if the target is in the range or not. It just makes the
logic a lot bigger.

The range-diff does not show any input sanitization - what happens when
the user passes "--reverse" for example? As I said in [4] we should copy
what "git replay" does to sanity check the rev-list options, otherwise
we've got no idea whether the parent of the first commit returned by
get_revision() is the commit we want to use as the parent of the
squashed commit.

Yeah, good point.


Harald