Hi, On Tue, 27 Jan 2009, Stephen Haberman wrote: > > 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? Yes, this will still work. AFAICT this is actually how git --no-interactive -p is implemented... > (Er, maybe I can just use rebase-p...I forget why [1] is using the > GIT_EDITOR=: with -i.) See above... :-) > 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. Maybe teach git pull about --rebase=preserve[-merges] and branch.<name>.rebase=preserve[-merges]? > 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. I always meant to handle that in the fast-forward handling of pick_one(). > 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. Well, let's see how things turn out once I use the patches for my own work... Thanks, Dscho -- 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
