Hello,
I've done some little experiments with rebasing a branch with merges on it. I
wanted to check that what I found is what is intended.
I made a repository like this:
* -- * -- * (master)
|\
| A (branch1) -- M (merge)
\ /
B (branch2) --
It's a horribly unfair thing to do, but while on merge I did
git rebase master
I had been hoping that both branches would rebase, but only one did. I got:
* -- * -- * (master) -- B -- M (merge)
|\
| A (branch1)
\
B (branch2)
"M" effectively now contains all of branch1's changes. If I hadn't referenced
the merge head separately from the two branch heads, all the history in
branch1 would now be represented by "M".
I don't think this is the right result. Either
* git should refuse to rebase because it would lose history
* git should rebase both branches
The ideal result (perhaps unrealisticly) would have been
* -- * -- * (master)
|\
| A (branch1) -- M (merge)
\ /
B (branch2) --
This is an unreasonable thing to expect a version control system to be able to
do - it's a nasty, complicated wish. git is its own worst enemy for things
like this; it's getting to be so good at nasty unreasonable things that they
don't seem like fantasy-land wishes.
A perfectly valid answer is "don't be so ridiculous Andy, go away". :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@xxxxxxxxx
-
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