git rebase --interactive squash/squish/fold/rollup

I was wondering if there was a git rebase --interactive "squash" alternative, that instead of letting me edit and manually combine the commit messages from multiple commits that I want squashed together, instead simply used the first and folded the other commits into that?

I often find myself in the following pattern:

branch, hack, commit. hack, commit, hack, commit git rebase --interactive master squash later commits into an earlier one repeated [hack, commit]+, rebase, squash merge

At which point, 99% of the time I want to fold the later commits into an earlier commit, keep the commit message of the first and throw the remaining commit messages into /dev/null.

I understand this is just a matter of editting the commit messages, but I'm lazy and I find myself repeatadly dumbly deleting the latter commit messages again and again.

A $EDITOR macro/extension might address this, but it seems (to me) cleaner to extend the rebase command set:

< pick, edit, squash

"fold" is perhaps the wrong word. "squish" is perhaps too similar. "rollup" maybe?

In any event, functionally it would do exactly the same as "squash", except rather than let you edit the commit messages it would instead simply use the commit message of the first commit. And throw the other commit messages away.

I'm not adverse at having a go at putting a patch together (although this is not my forte), but I thought I'd check there wasn't prior art or a good reason why this would be a "bad thing" to have?

Murray.

What if you used  commit --append  instead?

The trouble though of squashing all the commits into one is that it makes it impossible to bisect later. Are you really sure that your final commit cannot be broken into small commits? Ideally each commit is small but self contained. Squashing should be done only to fix cases where you introduced a bug then fixed it, or to fix a partial implementation etc.

John

On Wed, Jun 17, 2009 at 1:55 PM, John Tapsell <johnflux@gmail.com> wrote:

That appears to be a switch I don't have, nor is documented

http://www.kernel.org/pub/software/scm/git/docs/git-commit.html

Did you perhaps mean --amend?  Or have I missed something?

--amend is not really a solution for me - it is perhaps a quirk of my working pattern, but I typically (on the branch) commit tiny tiny bits of a (possibly incomplete) feature, then want to merge them back into a single "feature commit" to merge with trunk. It's a case of building up a feature commit one step at a time.

Perhaps I'm not normal or going about it wrong, in that I'm happy to commit (on a branch) an incomplete bit of code ... pop off to do something else, come back, hack a little more ... go off, come back ... eventually ending up with a bunch of commits I want to merge down into a smaller set of (combined) commits which to then merge with master/trunk.

fwiw, I didn't set out with this pattern in mind, it's rather one I have noticed myself being in frequently. It seems quite natural to me, except for this repeated squashing mini commits down. I'm not squashing ALL commits down into one single commit. Rather many commits down into a few commits, which then get merged with master/trunk.

John Tapsell <johnflux@gmail.com> writes:

I think you meant --amend, but it often happens to me that after preparing a three-patch series:

	[1/3] Clean up the surrounding code I will touch
        [2/3] Lay the groundwork
        [3/3] Implement a cool new feature

I find that there are more clean-up that should have been done in [1/3]. The way "rebase -i" expects me to work is:

	$ edit ;# more clean-ups
	$ git commit -a -m 'squash to "clean up"'
        $ git rebase -i HEAD~5

which will give me
        
        pick 1/3 Clean up ...
        pick 2/3 Lay the groundwork
        pick 3/3 Implement
        pick 4/3 squash to "clean up"

that I'll change to 

        pick 1/3 Clean up ...
        squash 4/3 squash to "clean up"
        pick 2/3 Lay the groundwork
        pick 3/3 Implement

and then I'll need to edit the commit message for the first two combined. More than half of the time (but not necessarily all the time), the edit involves just removing the single-liner 'squash to "clean up"',

You _could_ work this way instead using "amend". Immediately after finishing the three-patch series:

	$ git rebase -i HEAD~4

which gives me

        pick 1/3 Clean up ...
        pick 2/3 Lay the groundwork
        pick 3/3 Implement

that I'll change to

        edit 1/3 Clean up ...
        pick 2/3 Lay the groundwork
        pick 3/3 Implement

and then perform extra clean-up when "rebase -i" let's me amend the first one.

But this is much less convenient than being able to accumulate fix-ups as separate commits on top of the mostly finished main series, and then being able to later insert these fix-ups into the main series to be squashed using "rebase -i", if (and only if) what you need to do are many small fixups (imagine there are not just a single '[4/3] squash to "clean up"' but a lot more fix-up commits in the above example). Depending on the style you work, "go back to amend" is Ok, or you may even prefer to. But some people do not switch context as rapidly as others. After finding a small "missed piece", having to go back to edit and come back is much more heavyweight operation than being able to make a small "fix-up" commit on top and keep going. The latter keeps your thought process less disrupted.

And it is very likely that the "small fixups" won't change what the original commit log message of the commit in the main needs to say (otherwise they won't be "small").

So I can see why a variant of "squash" that does not change (nor even ask for a replacement of) the commit log message from the one that is being amended could be useful. I am tempted to suggest calling that a "fixup" operation, but some people may expect "fixup" to mean a variant of "edit" that does not bother you by dropping you back to the shell to touch the tree that is recorded (i.e. "fixing up the commit log message only"), so it is not a very good word.

2009/6/17 Junio C Hamano <gitster@pobox.com>:

Yeah. It would be nice to have a 'crush' or something here. It's similar to the arguments to have a command to just edit the commit message in a single go, rather than the rather long way of using edit.

One way could be to have arguments to squash in a way that was proposed for the sequencer GSOC project last year. For example,

commit 123456 squash -C HEAD abcdef

would just proceed with the commit of HEAD, and since squash is basically apply-to-index + commit, the HEAD would still be 123456.

Paolo

On Wed, 2009-06-17 at 12:33 -0400, Junio C Hamano wrote:

I wonder if a better approach might be to add an operator to squash rather than another verb. "squash!" maybe? This has the nice property that future verbs that have both interactive and non-interactive modes could be made consistent with squash easily, rather than having to think of another synonym.

We could also have edit! to just straight the commit message stage, and then automatically continue.

On Wed, Jun 17, 2009 at 09:33:19AM -0700, Junio C Hamano wrote:

How about deleting the commit message header?

pick c0ffee not to be modified commit message pick 012345 squashme ...

=>

pick c0ffee not to be modified commit message squash 012345 ...

It requires explicit removal the unwanted commit message, avoiding any accidents due to ambiguous keywords.

I'm quite liking this idea, albeit a subtle feature.  Which is just fine.

first port of call.  Along with the documentation.

I will see what I can put together, albeit not until next week now.

Thank you all for the input.

When the commit log message begins with "squash to ...", and there is a commit whose title begins with the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing come right after the commit to be modified, and change the action of the moved commit from pick to squash.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

  Quoting Junio C Hamano <gitster@pobox.com>:

  I think you meant --amend, but it often happens to me that after preparing
  a three-patch series:
  
      [1/3] Clean up the surrounding code I will touch
      [2/3] Lay the groundwork
      [3/3] Implement a cool new feature
  
  I find that there are more clean-up that should have been done in [1/3].
  The way "rebase -i" expects me to work is:
  
      $ edit ;# more clean-ups
      $ git commit -a -m 'squash to "clean up"'
      $ git rebase -i HEAD~5
  
  which will give me
          
      pick 1/3 Clean up ...
      pick 2/3 Lay the groundwork
      pick 3/3 Implement
      pick 4/3 squash to "clean up"
  
  that I'll change to 
  
      pick 1/3 Clean up ...
      squash 4/3 squash to "clean up"
      pick 2/3 Lay the groundwork
      pick 3/3 Implement
  
  and then I'll need to edit the commit message for the first two combined.

How about this patch? It does not let you say 'squash to "clean up"' but other people who are more skillfull than me can enhance such details.

 git-rebase--interactive.sh   |   31 +++++++++++++++++++++++++++++++
 t/t3414-rebase-autosquash.sh |   36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+), 0 deletions(-)
 create mode 100755 t/t3414-rebase-autosquash.sh

Hi,

On Thu, 18 Jun 2009, Nanako Shiraishi wrote:

I do not like this at all. It assumes that you never have valid commit messages starting with "squash to".

Ciao, Dscho

The 18/06/09, Johannes Schindelin wrote:

Plus, a commit message should not be anything else that a message about a commit. Please, don't make the Git's behavior depends on the commit message itself.

If we need a program to have various behaviours, we have:
- the compilation options;
- the command line options;
- the configuration files.

Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:

Sorry, but I have to disagree to such a dogmatic statement.

We do want our commands to be able to act intelligently and/or differently depending on what commit says in some cases. It is does not make sense to insist that the command line or configuration mechanism must be used.

A really trivial example. "git log -p" shows the patch text for non-merge commits but not for merge commits. "git log --grep=foo" shows only commits that says "foo" and "git log --author=Nicolas" shows only commits written by you. We used to leave an explicit note in the message part of cherry-picked commits where they were cherry-picked from; "git merge" and/or "git rebase" could have paid attention to it to act differently (i.e. "ah, even though that commit is not in the ancestry, the moral equivalent patch is already applied").

Besides, if you as the end user want to tell this and that commit are special among other commits that are being rebased to the command, which is the scenario Nana's patch is about, how would you do that from the command line option? "rebase -i --move=4-to-2 --squash=2"?

I do not necessarily think the behaviour suggested by the patch should be the default, but as an optional feature, it makes perfect sense for a command to pay attention to commit messages when deciding what to do.

IOW, I understand Dscho's objection that there is a risk that this feature may trigger when not wanted (but more on this later), and I'd be fine if it can fire only with an extra option, e.g. "git rebase -i --autosquash".

But from the workflow point of view, I think what the patch tries to do (I haven't studied the actual implementation carefully, so it may not be what it actually _does_) makes perfect sense, and it matches what I often do very well. Accumulate changes as a series of basically sound commits, queue some small "fix this breakage in that commit" commits on top of them while proofreading, and finish the series with "rebase -i" to reorder, squash and typofix.

Now, I initially had the same reaction as Dscho. What happens if I really want to write a commit message that begins with "squash to "?

But after thinking about it a bit more, I do not think it is as bad as it sounds anymore.

The commit not only must begin with "squash to " but also there has to be a matching commit whose message begins with the remainder of the title of the "squash to" commit _in the range you are rebasing INTERACTIVELY_.

In addition, the resulting rebase insn is presented in the editor, and in a rare case where you do have such a commit, you can rearrange it back.

Hi,

On Wed, 17 Jun 2009, Junio C Hamano wrote:

Well, that really sounds pretty awkward to me. I regularly call such commits "amend". If there is a risk I confuse myself as to which commit needs to be amended, I use "amend.<short-hint>".

I'd really rather stay with "fixup". And as I use single-letter commands quite often, I'd also rather stay away from that magic "!". And by "magic" I really mean that: people will not find that magic intuitive at all.

My vote is for "fixup".

Ciao, Dscho

A bit off-topic: I wonder if there is an easy way to make rebase run testsuite for the each commit it rebases, or even simple compile test, to not introduce untestable commits when rebasing by mistake...

Jakub Narebski <jnareb@gmail.com> writes:

I used to do that manually, i.e. s/^pick /edit /;

Hi,

On Thu, 18 Jun 2009, Junio C Hamano wrote:

This could be a command

	run-foreach (cd t && make)

Hmm?

Ciao, Dscho

On 2009-06-18 10:06 (+0200), Johannes Schindelin wrote:

I don't know about people but I do find "!" intuitive. It is squash after all so I like the idea of using small modifier character.

Mine is for "squash!".

Hi,

On Thu, 18 Jun 2009, Teemu Likonen wrote:

Mhm.

So let's just interpret the "!" in the most common meaning, namely to add an imperative. Then it means "yes, I do want to squash". Not "squash, but oh, BTW, I want to lose the second commit message completely, and I do not want to edit the commit message either".

Really, I do not see how anybody could find this intuitive at all. Maybe after reading the manual, but kinda defeats the meaning of the word "intuitive".

Ciao, Dscho

On 2009-06-18 10:29 (+0200), Johannes Schindelin wrote:

My main point is the "small modifier character" for squash. Perhaps "squash*" is better? I'll repeat that it is still doing very much the same thing as "squash" expect for one little thing. Hence it would be nice to use only small modifier character, not totally new word with possibly different connotations.

    pick aaaa ...
    squash* bbbb Small fix to be squashed
    pick cccc ...
    pick dddd ...

Hi,

On Thu, 18 Jun 2009, Teemu Likonen wrote:

If you think that putting a special meaning to a special character is intuitive, I have to inform you that you are mistaken.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Nice bike-shedding... But UI is hard to change later, usually.

Yet another proposition would be to simply remove subject to mark commit to be squashed without adding commit message to squashed result commit message

    pick aaaa ...
    squash bbbb
    pick cccc ...
    pick dddd ...

 Just my 2 eurocents.

On Thu, 2009-06-18 at 04:29 -0400, Johannes Schindelin wrote:

The imperative is actually the reason I picked that modifier, as in "yes, I /really/ do want to squash. Don't ask me, just do it!" Something akin to -f. I think it makes sense here, but not in the case someone else mentioned of a commit message only edit. ("recommit" for that case?)

In any case, I think this non-interactive squash is orthagonal to being able to automatically rearrange the commits by "squash to ...". I think that's a cool idea, but I know that I often don't remember the text of the commit I want to squash into. So in my case I prefer rearranging manually and squashing non-interactively. If I planned ahead, I could pick a prefix for each "class" of commit, and then "squash to prefix", but I'd want to be able to edit the original commit to remove the prefix. Sure, I could look at the log, but if I'm just writing a nonsense message to remind myself where to squash to, I think it would get in the way of my flow.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I am too tired to either make the final judgement nor proposal on this topic now, but before I forget here is one tangent.

I also often use "magic" commit log message in other occasions. The most important is "[DONTMERGE]" prefix to somebody else's commit I queue to 'pu' (or leave unmerged even to 'pu'---just keeping on a topic branch). I accept a patch with "am" and then "amend" after review when I find that it needs more work. One day I am hoping to write a pre-merge hook that forbids commits marked with such magic to come into 'next' and down.

The point?

Earlier somebody objected to a command that changes behaviour based on what is in the commit log message, but for the private commits the patch under discussion deals with and the ones I mark with "[DONTMERGE]", the commit log message _is_ the right place to leave a mark for commands to take notice and act differently.

Of course we _could_ use notes for that, but that won't play well with rebasing I suppose ...

Hi,

On Thu, 18 Jun 2009, Junio C Hamano wrote:

Okay, I'll add another point that should convince you that the commit message is not the good place to trigger that behavior:

Interactive rebasing is about having made a quite messy patch series, maybe having a few fixup commits, and then deciding how to clean it up.

The decision how to clean it up is very much a rebase-time decision, not a commit-time decision.

For example, it is very easy to decide that you want to squash one fixup after all instead of leaving it stand-alone.

Reminds me.  Nothing has happened on that front, right?

Ciao, Dscho

Johannes Schindelin venit, vidit, dixit 18.06.2009 10:33:

<!--#if expr="$SARCASM_ON" --> No, but isn't that the true purpose of out-sourcing? You've got someone else to blame now! <!--#endif -->

Cheers, Michael

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I agree.

Magic commit messages are not good for this kind of thing.

-Miles

The 18/06/09, Junio C Hamano wrote:

Not for now; you're right. But what I see here is all about commit/branch metadata to make our like with workflows easier.

What about implementing a true metadata feature into Git? There are a lot of nice possible functionalities around metadata.

Fast, stupid and superficial thoughts on that:
- have metadata to make git to act differently and/or for information
  purpose;
- let the user create its own metadata for his own purpose;
- let the user have hooks script where appropriate.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I like fixup. I'd say "fixup: <message>" so that the thing actually looks like a program directive rather than natural language.

(I disliked this at first, but I may actually like it if it gets into Git!)

Hi,

On Thu, 18 Jun 2009, Matthieu Moy wrote:

Umm...  The thing would be used like this:

original edit list:

	pick b1ab1ab First commit
	pick deafbee Second commit
	pick 0123456 This is a fixup for the first commit

edited edit list:

	pick b1ab1ab First commit
	fixup 0123456 This is a fixup for the first commit
	pick deafbee Second commit

It would squash the first two commits, forget about the second commit message and continue with the last commit. No user interaction unless there are merge conflicts.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

[...]

Sorry, we were not talking about the same thing: I was still talking about the dwimery in the commit message. So, yes, your "fixup" (that could be abbreviated by "f") sounds good to me.

But some (optional) magic to get the edited list by default could be nice in addition, and that could be triggered by "fixup: ..." in the commit message.

I do often find myself commiting something knowing that the commit is meant for rebase+squash-ing (i.e. I know that at commit time more often than at rebase time).

(not yet 100% convinced myself, and I can sure do without)

The 17/06/09, Junio C Hamano wrote:

But I see a huge difference between a message added by the program itself to act well on possible comming cases and a message added by the user to act differently at the commit time.

The latter case is exposed to the user mistakes (wrong typo, unintentional matching pattern, etc) which could leave the repository in unexpected states.

Git is enough hard to learn. Please, don't make the learning curve even worse. Having the commit message possibly making git acts differently is not usual or expected by most users.

Well, as we always squash to one of the first direct ancestor and as squashing to a merge is not usual (here at least), in most cases it just gives "rebase -i --move=4-to-2" wich sounds reasonable enough to me.

Nanako Shiraishi <nanako3@lavabit.com> writes:

I have to admit that I wished to see something like this for more than once. It would have been nicer if the patch went one step further and did "squash the patch, but use the log message from the commit that is squashed into, without even asking for a consolidated message", but I think it is a reasonable start.

But as Dscho already objected to, this is a new feature that is potentially dangerous --- there is a risk of matching a commit that was not intended for squashing, albeit small. We may want an explicit option to enable it. On the other hand, you may be able to argue that use of "interactive" rebase is already a sign that the user is likely to want such a convenience, though.

I guess we could even loosen this "must match the leading substring exactly" restriction if we can expose Dscho's Levenstein to Porcelain writers.

Do you really want to break here? What happens if I have more than one fixup patches to the same commit?

These tests want to be stringed together with && to catch possible breakages during the setup. The same for the real test below.

Not just count, but you would want to make sure that the rewritten "first commit" now has the desired tree ("1" instead of "0" in file1, if I am reading the test correctly).

Teach a new option, --autosquash, to the interactive rebase. When the commit log message begins with "!fixup ...", and there is a commit whose title begins with the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing come right after the commit to be modified, and change the action of the moved commit from pick to squash.

This will help the use case outlined in

    From: Junio C Hamano <gitster@pobox.com>
    Date: Wed, 17 Jun 2009 09:33:19 -0700
    Subject: Re: git rebase --interactive squash/squish/fold/rollup
    Message-ID: <7vvdmurfao.fsf@alter.siamese.dyndns.org>

and further explained in

    From: Junio C Hamano <gitster@pobox.com>
    Date: Thu, 18 Jun 2009 00:54:47 -0700
    Subject: Re: [PATCH] rebase -i: auto-squash commits
    Message-ID: <7vws7ayo1k.fsf@alter.siamese.dyndns.org>

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

Changes from my yesterday's patch are as follows.

 * The feature is disabled by default; the user needs to explicitly ask for it with --autosquash option.
 * Squashing more than one commits to the same commit should work.
 * The commit message must begin with a more magic string "!fixup" instead of "squash to".
 * Commands in the test script are joined with &&.
 * The test examines the content of the file to verify that the commit was correctly squashed.
 * Add documentation.

 Documentation/git-rebase.txt |    9 +++++++++
 git-rebase--interactive.sh   |   35 +++++++++++++++++++++++++++++++++++
 t/t3414-rebase-autosquash.sh |   37 +++++++++++++++++++++++++++++++++++++
 3 files changed, 81 insertions(+), 0 deletions(-)
 create mode 100755 t/t3414-rebase-autosquash.sh

2009/6/18 Nanako Shiraishi <nanako3@lavabit.com>:

Can I suggest to rename it into "--autofixup"? Or even "--auto=!fixup"? Just so that people have one thing less to remember.

El 18/6/2009, a las 23:55, Nanako Shiraishi escribió:

Definitely a fairly common workflow for me. Faced with a sequence like this:

	[1/3] Cleanup
	[2/3] Lay groundwork
	[3/3] Implement feature
	[4/4] Doh! more cleanup that should have gone in [1/3]

I usually just let 4/4 stand as a separate commit with a message like:

	More cleanup of XYZ

	Ideally this should have been included in commit abcd1234,
	but wasn't noticed until too late.

Seeing as I'm not perfect, I don't necessarily spend time manipulating the history to make it appear that I really am perfect.

Even so, if asked to imagine an ideal workflow for this scenario, I don't really want a new switch for "git rebase -i", but rather the ability to do "git commit --amend" on a non-head commit. (I know this has come up on the list back in February under the subject "FEATURE suggestion git commit --amend <ref>".)

Basically, if you do the following:

	edit
	git add foo
	git commit -m "Cleanup"
	edit
	git add foo
	git commit -m "Lay groundwork"
	edit
	git add foo
	git commit -m "Implement feature"
	# doh! found stuff that should have gone in in step one!
	edit
	git add foo
	git commit --amend HEAD~3

My intention would be for git to actually:

	1. Create a temporary throw-away commit (without updating the HEAD)

	2. Do the equivalent of using "git rebase -i" to squash that  
temporary commit into the HEAD~3 commit, providing you with the  
opportunity to edit the adjust the commit message if necessary.

	3. In the event of failure to replay the other commits on top, you  
would want the process to dump you back where you started (same HEAD  
as before, with same changes staged in the index) and an error message  
informing you that the changes didn't apply cleanly and that you  
should use "git rebase -i" instead to walk through the process manually.

At least for me that would be the ideal interface to this kind of feature. I can't really see myself using these magic commit messages and the --autosquash switch.

However, the "FEATURE suggestion git commit --amend <ref>" thread caused a lot of objections to be raised. Things like:

	- what if <ref> is a merge?

	- what if there are merges between <ref> and the current HEAD?

	- what if the amendment breaks reapplication of later commits?

	- what if <ref> is not an ancestor of the current HEAD?

	- what if <ref> is part of more than one branch? (and would the user  
be confused if it was only rewritten on one branch?)

Basically as I see it, the kind of workflow being discussed here should only be for the simple case of amending really simple histories (basic topic branches) and should bail loudly if pretty much any of the above conditions are true.

Cheers, Wincent

Quoting Wincent Colaiuta <win@wincent.com>:

I don't think it is about pretending to be perfect. If you are preparing a patch series to be reviewed, it is a minimum required courtesy to the reviewers to remove such earlier mistakes before submitting. It is called "making your series presentable."

I think you didn't read the explanation by Junio (the second message I quoted) why that is only one of the options, and isn't a satisfying solution for him. He explicitly said that he doesn't want his momentum disrupted by having to go back before he finishes the series, while admitting that the way you suggest may fit other people's workflow better.

As to the extra option, I don't like it, either (my original patch didn't have it). I added it only because Johannes Schindelin objected to the patch that the feature can trigger unexpectedly.

Nanako Shiraishi wrote:

It seems to me that even this requires more steps than strictly necessary, namely a commit then a rebase, and conveying the information from the commit step to the rebase step is somewhat awkward. Since I have to specify a magic commit message to trigger this behavior, I obviously know at the time of the commit that I want to squash the new changes onto an older commit. So why not implement this functionality as a variant of "commit"? Something like:

git commit --fix=old-commit

which would commit the changes in index as an amendment to the specified old-commit (requiring no new log message) and then rebase later commits on top of the new (combined) commit.

If a conflict arises while applying the changes in index to old-commit, then probably the whole process should be undone and aborted. If a conflict arises while rebasing later commits on top of the combined commit, then the usual rebase conflict-handling machinery would be invoked.

Michael

Michael Haggerty <mhagger@alum.mit.edu> writes:

That may be a good feature, but that won't work as well as the patch being discussed for _me_.

IOW, I think what you are suggesting is a different feature.

It largely depends on how you work. I do not function well when I get interrupted and/or disrupted often, and I would prefer the convenience of being able to simply queue a trivial patch with a minimum amount of fuss (e.g. just leave a note that says "to be squashed to that other one" and nothing else) when I find a trivial breakage that is unrelated to what I am concentrating on.

Imagine the "Clean up the surrounding code" then "Lay the groundwork" and finally "Implement a cool new feature" sequence I outlined in the message the patch was response to. When I thought I am finished cleaning up the surrounding code and laid the groundwork, and finally concentrating on implementing the new feature (which is the fun part), I may notice small breakages and untidiness I could squash into earlier commits.

It is very distracting, however, if I have to go back to the state _before I wrote all the fun code for the new feature_ to fix the breakage right there. Once I go back, the surrounding code would look all different, and I may even be tempted to do the full test cycle before finishing your "amend in the past" operation. The distraction will destroy my momentum and concentration.

It's much more easier on my brain to commit the fix-up to be later squashed (use "add -p then commit" for that) and continue. I can keep the momentum going that way.

But that is how _I_ work. You may well work differently, and for you "stop, switch brain back to the state before all these fun work and amend, then finally come back" workflow may work better.

What I am saying is that "a variant of commit" you talk may be good but it won't be a _replacement_ for the effort to make squash easier to do while running "rebase -i".