Johannes Sixt <j6t@xxxxxxxx> writes: > Today I was able to use rebase -i -p in the field. I used it to rebuild > an integration branch (akin to git's pu branch). Guess what? It did not > work as expected: > > Two of the topic branches' early parts were already merged in the > upstream. The instruction sheet had only 'pick' of merge commits for the > topics. Except for these two; there, all commits (that were not yet in > upstream) were offered to pick, including the merge commit. > > I started with this: > > A--M--o--o <- master > / / > --o--X--Y <- side branch (partially merged in master) > \ \ > R--S--N--T <- integration (to be rebuilt on master) > > I wanted this: > > A--M--o--o > / / \ > / / R'--S'--N'--T' > --o--X--Y---------------´ It is unclear what exact revisions you gave to rebase, but I am assuming that you asked "rebase --onto master X^ T" (you can use R^ instead of X^; they refer to the same commit). It is straightforward to see what should happen to R and S; they should be a straight replay of single parent commit on top of 'master'. But it is unclear what should happen to X and Y. When you are rebasing the X^..T sub-DAG, can you say what makes S more special than Y by looking at the original topology? Your "I wanted this" picture depicts S' to be rewritten but Y stays the same. Why? They are both in the X^..T DAG, and neither of them is merged to 'master'. I can sort of see why X and R would be treated differently (X is part of master, R is not), but I cannot justify why your "I wanted this" picture replays S' without replaying Y'. What am I missing? > But I got this: > > A--M--o--o-------Y' > / / \ \ > --o--X--Y R'--S'--N'--T' Which is what I would expect, from the "Y and S play a similar role in the sub-DAG X^..T in the original DAG, with respect to master" point of view. -- 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