Stephen Haberman wrote:
# A --C------ <-- origin/stable
# \ | \
# B -- D -- E -- F <-- origin/topic2
# \|
# g -- h <-- topic2
Nothing has changed. g & h haven't moved...I can keep executing this
operation and the commits never make it on top of origin/topic2's F.
Frustratingly, if I run non-interactive rebase, it works perfectly.
I can imagine. Since you don't want to preserve the merges in this
case, you shouldn't be using the -p flag.
No, I do want to preserve most merges. This "most" qualification is
because the merge "g", if rebased, would have been a no-op, so `rebase
-i -p` correctly kept it out of the TODO file.
Which is cool, except that later on, when rewriting the other TODO
commits, some of which were children of "g", it did not remember that
"g" had gone away, so did nothing to take "g" out of the rewritten
children's parent list.
In fact, for this particular scenario (assuming "h" is really the only
commit on topic2), you probably want to just cherry-pick that commit
into origin/topic2:
git checkout topic2
git reset --hard origin/topic2
git cherry-pick ORIG_HEAD
Agreed. This makes a lot of sense for me, who has been hacking around in
git-rebase--interactive fixing things, but I'd really like the other
people on my team to just have to run `git rebase -i -p`.
I don't think you can have a single command that does all the things
you want, because the possible differences in input makes it very
nearly impossible to always do "the right thing".
Ah, you are too pessimistic. :-)
Perhaps, although I think you're being overly optimistic if you think
rebase can do all of this intelligently while still retaining clear
semantics. I'd start with writing a separate tool for it, probably
based on git sequencer. When that works out ok, get it to do what
rebase does today and then incorporate the new tool as an option to
rebase and get ready to answer complex questions for the cases where
it doesn't do what the user wanted it to do.
Git is stupid very, very much by design. Linus constantly says that
he prefers tools that he can figure out why they did something stupid
over tools that try really hard to get it right, and I agree with him
100%, as do most of the core contributors (insofar as I've understood
it). What you're suggesting is that a git command should try hard to
dwim a lot of complexity about choosing tools away, and that goes
right against the KISS principle which serves git so well. I'm not
saying you shouldn't do it. Merely that you should think hard about
it and then make sure it doesn't break anything people are already
doing today with the current toolset.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
