Nanako Shiraishi wrote: > 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. 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 -- 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