Marc Branchaud schrieb: > Johannes Sixt wrote: >> If I were to re-merge topic into master a second time after this >> situation, I would install a temporary graft that removes the second >> parent of M and repeat the merge. After the graft is removed, the history >> would look like this: >> >> B --- C --- D --------------. [topic] >> / \ \ >> A --- ... --- M ... --- U ... N [master] >> >> Are there any downsides? I don't know - I haven't thought it through. > > I'm not sure I follow how to create that graft. $ echo $(git rev-parse M M^) >> .git/info/grafts > But the original point (which I hadn't made clear) is that at least one of > the topic's commits needs to change in some substantial way. So it's not > just a straight re-merge but a new take on the topic. > > Consider that if the topic's first commit (B) needed to be rewritten then the > repaired topic would contain only new commits and it could be merged into > master without reverting the first merge's reversion. You don't need --ff nor --no-ff in this case. > What "rebase -i --no-ff" does is allow you to ensure that this will always be > the case, even if you don't actually need to change the topic's first commit. But why do you base the reworked topic on A instead of U or later? Or why don't you just mark the first commit as r(eword) and just exit the editor; it would rewrite the commit and all subsequent ones will be rewritten as well. Never in my life would I have searched for a *option* that achieves the goal. It is such a rare situation that we don't need an option, do we? -- Hannes -- 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