Pete Harlan <pgit@xxxxxxxxxxxx> writes:
> I imagine an ideal version of this fix would make it so the use case I
> presented here would work, but rebase -i would still prevent
> introducing a new empty commit, or at least warn when it was
> introducing one. In the absence of that ideal fix, I think this
> behavior is better than failing to handle this case.
Sorry, I actually tend to think that in the absense of that fix, your
version introduces risky behaviour that only a corner-case use case
benefits, and pros-and-cons doesn't look attractive enough.
Why not do something like:
pick X a crap tree with a good message
pick Y revert X
pick Z a good tree with a crap message
-->
# drop X
# drop Y
edit Z
and then run "git commit --amend -C X" when it is Z's turn to be
processed?
--
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