Re: [PATCH/RFC] Allow empty commits during rebase -i

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 18, 2010, 01:29 UTC
Message-ID: <7vljfww686.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B53B561.0@pcharlan.com>

Pete Harlan <pgit@pcharlan.com> writes:

Show 5 quoted lines

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