Re: Heads up: major rebase -i -p rework coming up

From: Stephen Haberman <stephen@exigencecorp.com>
Date: Jan 27, 2009, 15:21 UTC
Message-ID: <20090127092117.d13f24e7.stephen@exigencecorp.com>
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>

> I am very sorry if somebody actually scripted rebase -i -p (by setting
> GIT_EDITOR with a script), but I am very certain that this cleanup is
> absolutely necessary to make rebase -i -p useful.

I have scripted rebase-i-p, but with GIT_EDITOR=: [1]. I assume this will still work and just accept the default script?

(Er, maybe I can just use rebase-p...I forget why [1] is using the GIT_EDITOR=: with -i.)

My primary pain point with rebase-i-p has been rebasing a branch that has merged in another branch that has a lot of commits on it. E.g.:

    a -- b -- c  origin/feature
      \
       d -- e    feature
           /
      ... g      origin/master

Where e is merging in, say, a latest release that had a few hundred commits in the master branch. After resolving conflicts/etc. in e, I want to rebase d..e from a to be on c.

The two problems have been:

1) `git pull` with rebase set uses rebase-i, with no -p, so all of the
   commits from the latest release branch that got merged in with e are
   flattened/duplicated. This is what [1] tries to fix. I've made
   noises about hacking the branch rebase flag but haven't followed
   through.

   I know this is a git pull issue, but I bring it up because, IIRC, the
   t3410 test case came from a scenario where I was rebasing a merge
   like e above and due to --cherry-pick dropping a commit (probably e
   itself, I'm not sure), rebase-i-p as it existed then broke and
   produced a noop. So I set off to get it to do "something" and ended
   up introducing the "DROPPED" directory.

2) With manual invocation of `rebase-i-p`, previously you'd get a
   laundry list of commits from the e merge that are new to the feature
   branch, but since g and its ancestors aren't changing, you don't need
   to consider them in the script and so its (potentially a lot of)
   noise. This is what the parent probing back port from git sequencer
   addressed.

So, I don't mean to rehash old complaints, as I'd love to see the rebase-i-p code cleaned up by someone who can really refactor it vs. my hack patches. But I wanted to emphasize the motivation for my hacks over their implementation so that hopefully you can still address these use cases in the new version.

Thanks, Stephen

[1]: http://github.com/stephenh/git-central/blob/master/scripts/pull