Re: [PATCH v7 0/5] history: add squash subcommand to fold a range

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Jul 7, 2026, 07:51 UTC
Message-ID: <CAHwyqnVxa34iGmFvL4Ujrc2dTbmtF+7j7b=q5v95y=-pzUf0NA@mail.gmail.com>
In-Reply-To: <5a5dbfae-4525-4b00-9e44-936be606ee85@gmail.com>

> 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.

Show 12 quoted lines

> >     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.

Show 6 quoted lines

> 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