From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 18 Jan 2010 01:29:29 GMT
Subject: Re: [PATCH/RFC] Allow empty commits during rebase -i
Message-ID: <7vljfww686.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B53B561.0@pcharlan.com>

Pete Harlan <pgit@pcharlan.com> 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?