Fabian Ruch <baf...@gmail.com> writes: > Your reply suggests that git-rebase--interactive was wrong from the > beginning and that the replay of commits without any message should be > allowed. This would reconcile the first case with the second. In fact, > since neither of them alters the changes introduced by $1 or its log > message, it might be incorrect to complain about a missing message in > the first place. > ... > Do you want me to replace this patch with a patch
Now you explained your line of thought more clearly and I have thought about it a bit more, I think I agree with the conclusion of the above. An alternative may be to teach a new option --allow-empty-message to rebase to allow people to replay/reproduce an existing history with commits without any message, and uniformly tighten to refuse replaying a commit without message by default. But I am not sure if that is a good direction to go. Doesn't "rebase" without "-i" by default replay a commit without message faithfully? It might be debatable to allow a commit that we would normally would flag as suspicious (i.e. no change relative to its parent, or no log message) when replaying with "reword" or "edit", but when replaying with "pick", "rebase -i" should behave just like "rebase" without interactive. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
