Michael Haggerty <mhagger@xxxxxxxxxxxx> 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". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html