Re: [PATCH] rebase -i: auto-squash commits

[Junio C Hamano <gitster@pobox.com>]

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

> 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"?

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