On 06/21/2011 08:11 AM, Matteo Cypriani wrote: > The thing is, my M was not a "simple merge commit", but contained some changes > needed for the code in master and topic to work together. In that case, git > rebase -i -p recreates a merge commit, but it does not keep the changes > introduced in M. > > Is there any way to keep the M's changes in my case (except to manually patch > & amend the re-created merge commit) ? > Unfortunately, I don't think there's any nice way to do it right now. I think what you could do for now is make the "pick <M>" into a "edit <M>", together with other changes you want to make. And then when you get to "edit M", do a "git cherry-pick -n -m 1 <M>", or "-m 2" depending on how your merge was done. That should bring your changes over. Then you just need resolve and add any conflicts, and do a "rebase --continue". I've only tried it on a simple case and that seems to work. > If not, maybe it would be a nice functionnality to implement ? > I imagine this is pretty useful feature to have too. I could look into adding this support when I got a chance. I haven't given it much thought yet though, so I don't know how feasible it is. -- 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