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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Fabian Ruch <bafain@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]