Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > I think Junio is referring to this thread: > > http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121874 Yes, that was the one I had in mind, and it is a shame that we somehow ended up not taking it, perhaps in an improved form, back then. Even today alone, I missed the "mark for later fixing/squashing and then rebase at the end" feature twice at dayjob. > I too think Michael's "fix" is a good feature, and in the > workflow by Shawn, he knows he is fixing up an earlier > commit, and he knows he doesn't want to add anything to > the message by the fix-up commit when he makes that commit > (how else would he have messages like "a", "s", or "foo"). There is a slight distinction between "Shawn's fix-up commits have garbage message and he does not want any part of them in the final commit message" and "Shawn is happy with the message of the original commit whose tree these fix-up commits are meant to correct." He may still not be entirely happy with the original message. Wanting to edit the commit log message, and not wanting to use the messages from follow-up commits, are two different things. I would agree that it is a good idea for "rebase -i" with only "fix" and not "squash" to skip the editing of the final message. You manually move, or tell your "rebase --autosquash" option to automatically move, the follow-up commits next to the ones they are meant to correct while editing the rebase-i insn, and you change their "pick" to "fix" (or "fixup" as Dscho and others suggested in the earlier round you quoted) only when you know you want to keep the message of the original commit. Otherwise you can change them to "squash" not to "fix", and you can edit the final log message that way. If Michael rolls his second round with your "--autosquash", or you do so yourself on top of his patch, I think it _might_ be safer to mark the ones automatically moved as "squash", and not as "fix", and have the users explicitly change the "squash" they want to "fix" themselves. Alternatively, you can also use two magic tokens (i.e. instead of one "fixup!", allow people to use "squash!" and "fixup!") and change the action chosen for the moved commits to "squash" and "fixup" respectively. > I don't think your objection should block *others* (like > Shawn and Junio) who can decide when they make commits > from using the feature from my old patch to make it even > easier to clean up their topics. If *you* can't decide if > you want to amend or not when you make a fix-up commit, you > can leave your fix-up commits unmarked, run interactive > rebase without the --autosquash option, and use Michael's > 'fix' manually. People who can sometimes but not always > decide when they make commits can do the same when they > can't. > > Isn't it what Junio suggested by his "on top of this feature", > and wouldn't that make everybody happy? The answer to the first question is "yes"---I did't understand why Dscho objected to a feature he can choose not to use if he doesn't want to, and I still don't (unless I was misreading your earlier patch back then and it somehow forced all rebase-i users to decide upfront at the commit time, but I highly doubt it). I don't know about the second one but I am guessing it would also be "yes". -- 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