Junio C Hamano wrote: > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > >> In particular, "reword" should cherry-pick a reworded commit even if the >> commit's message is unchanged. >> >> This behaviour provides a way to deal with a situation that can arise when >> a merge had to be reverted. Added an addendum to revert-a-faulty-merge.txt >> describing the situation and how to use "reword" to handle it. >> --- >> >> Is this more acceptable than adding --no-ff to rebase--interactive? >> >> I wasn't sure how to integrate the new text into revert-a-faulty-merge.txt. >> I went with an addendum, but I'm open to other approaches. > > The addendum looked readable, but I am a bit puzzled. Ya think _you're_ puzzled? :) > "rebase -i --no-ff" > already exists, and is probably a more natural way to do this than saying > "reword" but not rewording anything, no? > > I would actually say "rebase -f P" would be even easier and clearer, > especially as... > >> ... >> +However, you could avoid these problems if you recreated the entire branch, >> +including commit A: >> + >> + P---o---o---M---x---x---W---x >> + |\ / >> + | A---B---C <-- old branch >> + \ >> + A'---B'---C' <-- entirely recreated branch >> + >> +Now you can merge A'-B'-C' into the mainline branch without worrying about >> +first reverting W. >> + >> +But if you don't actually need to change commit A, then you need some way to >> +recreate it as a new commit with the same changes in it. > > ... this part seems to talk about working around the tendency of 'rebase -i' > to fast-forward. Yes. Thanks for pointing this out, it's cleared up a lot for me. I was confused about the purpose of "rebase -f". Jonathan Nieder even pointed me to it when I posted my original patch for "rebase -i --no-ff", but the description in the man page threw me: Force the rebase even if the current branch is a descendant of the commit you are rebasing onto. Normally the command will exit with the message "Current branch is up to date" in such a situation. I didn't realize that this is exactly the situation that "rebase -i" normally deals with (-i basically implies -f), and that "rebase -f" would do exactly what I wanted "rebase -i --no-ff" to do. But I think I see an approach that might make sense: - Teach "rebase -i" to recognize the -f parameter (instead of --no-ff). - Update rebase's man page to better explain -f. - Update revert-a-faulty-merge.txt to explain how to use "rebase [-i] -f". I'll submit a new patch shortly. 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