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
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.
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