JK> On Thu, Jun 16, 2011 at 12:43:00PM -0700, Junio C Hamano wrote: >> >> Hi list. There were 2 branches. One's HEAD was modified to match a >> >> specific commit at another branch. Now, how to merge them according to >> >> this scheme? >> >> >> >> A---B---X---E---F >> >> => C---D---X---E---F >> >> C---D---X' >> >> >> >> X and X' have no difference. I tried to write a script to cherry-pick >> >> E and F, but some of commits are merges and cherry-pick fails. >> > >> > I think you just want to rebase using the "-p" option to preserve >> > merges. Something like: >> > >> > $ git checkout -b rebased-branch F >> > $ git rebase -p --onto D B >> > >> > that will pick X, E, and F, and replay them on top of D, resulting in >> > the graph you showed above. >> >> Eh, careful. Nobody said the change between B and X is any similar to the >> change between D and X'. Replaying the changes E and F introduce on top of >> X' to arrive at C--D--X'-E--F is the best you could do, i.e. JK> I thought that was exactly what Ilya said with "X and X' have no JK> difference". I assumed that meant "they are semantically similar commits JK> on different bases" (i.e., a cherry-pick) and not "they have the exact JK> same tree state" (i.e., "git diff X X'" is empty). >> But wouldn't filter-branch a better tool for this? Graft to pretend that >> the parent of X is D instead of B, and filter the branch with F at its >> tip, that is. JK> If my assumption on the meanings is reversed (i.e., X and X' really are JK> the same tree state, not introducing equivalent commits), then yeah, JK> that would be better. JK> -Peff sorry, git diff X X' is empty -- -- 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