> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
