From: Harald Nordgren Date: Tue, 07 Jul 2026 07:51:33 GMT Subject: Re: [PATCH v7 0/5] history: add squash subcommand to fold a range Message-ID: 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. > > 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