Peter Baumann <waste.manager@xxxxxx> writes: > This was mentioned before on the list (sorry, don't have a reference, > but it was a long time ago). AFAIR the reason it wasn't implemented yet is that > you will lose the commit message, which might contain precious information. I don't recall ever seeing that justification; and I don't agree with it either. As far as the resulting history is concerned, that commit does not even exist and there is no precious information. This is a tangent, but I suspect that in the very old days, after a "git rebase" stopped due to a conflict to have you adjust the change by resolving conflicts, "git rebase --continue" may have offered you an opportunity to edit the commit log message so that you can record what was made unnecessary (or made additionally necessary) compared to the original patch due to rebasing. I don't offhand know when we lost that feature (it is possible we never had anything like that and I am misremembering things). We may probably want to add it at least as an optional feature. After "git rebase" stops due to a conflict, and your resolution ends up to be not an empty change, "git rebase --continue" seems to simply reuse the original description these days. It might be a good default, but in cases where the conflict resolution made the change very different from the original, the old log message may not describe why the change was needed and how the change solved that issue properly in the context of the new history. "git commit -a -c .git/rebase-apply/original-commit" followed by "git rebase --skip" is a workaround that is too ugly to be called "workable" for it. Perhaps "git rebase --edit --continue" or something? -- 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