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

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

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

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