Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH RFC v2 06/19] rebase -i: Stop on root commits with empty log messages

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:01:52

Fabian Ruch [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help