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. "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. -- 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