Re: odd behavior with git-rebase

From: Phil Hord <phil.hord@gmail.com>
Date: Mar 26, 2012, 22:53 UTC
Message-ID: <CABURp0oP3YBEhpDrAL-mvt1dR+ZH3av-P_sqDQAdgcN10WS2ig@mail.gmail.com>
In-Reply-To: <4F70E53E.6060608@gmail.com>

On Mon, Mar 26, 2012 at 5:53 PM, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:

Show 24 quoted lines

> On 3/26/2012 12:20 PM, Neil Horman wrote:
>>
>> On Mon, Mar 26, 2012 at 10:12:48AM -0700, Junio C Hamano wrote:
>>>
>>> Neil Horman<nhorman@tuxdriver.com>  writes:
>>>
>>>> I agree, I think perhaps adding an --allow-empty option to the rebase
>>>> logic, so
>>>> that empty commits (or perhaps just initially empty, as opposed to
>>>> commits made
>>>> empty) would be very beneficial.
>>>
>>>
>>> Yeah, that probably may make sense.
>>>
>> Ok, cool, I'll have a patch in a few days, thanks!
>>
> IMO, it seems like --allow-empty is an appropriate patch for git-rebase
> (non-interactive), and that git-rebase -i would need a command like "k"eep
> to distinguish which empty commits are not to be discarded and which empty
> commits are ok to discard automatically.  git-rebase -i should allow
> explicit control on a commit by commit basis as opposed to blanket rules
> like "discard all empty commits" or "keep all empty commits" that apply to
> all commits in the rebase-to-do list based on a single cli option.

But I don't want a 'keep-even-if-empty' option in interactive. I want a 'purge-if-empty' option instead. But I don't want to be bothered with telling git this for every commit.

I recently had a long-running branch to clean up. It was polluted with commits pulled in by a ham-fisted developer collaborating on this and another branch. He's not quite got the git mental model yet and he had lots of commits doing things and then undoing them later on. Rebase scares him.

So I did a lot of interactive rebasing on this branch to reorder the "good" change commits to the front of the line where they could be pushed to code review sooner. In the meantime, I wanted to keep the rest of the branch in place so I could see what was left to tackle.

I cherry-picked replacements for many of the "good" commits -- from their original topic branches HamFist swiped them from -- so I would have the current, reviewable commit to push. Then I tested the long-running branch on top of these commits. This involved about 8 or 10 passes through 'git rebase -i master' for one reason or another.

On this branch of 40 commits, git interrupted me about 10 times on each pass to ask me what to do. The reason is always one of these:

  1. There is a new conflict I need to resolve
      examine / mergetool / test / --continue

  2. There is a rerere autoresolved conflict git wants me to approve
      examine / test / --continue

  3. There are no changes left in this commit because either
        a. they were introduced into earlier commits, or
        b. git-rerere-membered that I don't want those changes
      examine / --skip

I went through this process about 5 or 6 times as I massaged the stink
out of this branch.  Cases 2 and 3 became more common as I went along.
 But git always wanted to stop and ask my approval before continuing.
It was frustrating.

I always had my original branch to go compare to. This one is really a trial rework of these commits. So I wish I could tell git to only bother me when he sees a new conflict. Don't stop and ask me for something every 3 or 4 commits.

I really wanted something like this:

   $ git rebase --purge-empty --accept-rerere-authority -i master

So, even though this is an "interactive" rebase, I wish git would do more of the busywork for me. That is, I only want it to be as interactive as it needs to be, and no more so.

Phil