Johannes Sixt wrote: > 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? I want the topic based on A so that I can merge it into other branches that are also based on A. > 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. Yes, that works just as well (at least until someone optimizes the reword command). > 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? That's a more fundamental question. I don't feel strongly either way. The main advantage I see with having the option is that it codifies the process, with documentation and a unit test to help make sure it doesn't break. So if nobody wants the new option, I would then like to add a unit test to ensure that rebase's reword command doesn't get optimized (if such a test doesn't already exist), and maybe also add a note to the revert-a-faulty-merge howto. M. -- 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