Linus Torvalds <torva...@linux-foundation.org> writes: > It would be a *horrible* mistake to make "rebase" the default, because > it's so much easier to screw things up that way. > > That said, making "no-ff" the default, and then if that fails, saying > > The pull was not a fast-forward pull, please say if you want to > merge or rebase. > Use either > > git pull --rebase > git pull --merge > > You can also use "git config pull.merge true" or "git config > pull.rebase true" > to set this once for this project and forget about it. > > That way, people who want the existing behavior could just do that > > git config pull.merge true > > once, and they'd not even notice. > > Hmm? Better yet, make it per-branch.
I would assume that "no-ff" above was meant to be "--ff-only" from the first part of the message. I also would assume that I can rephrase that setting pull.merge (which does not exist) as setting pull.rebase explicitly to false instead (i.e. missing pull.rebase and pull.rebase that is explicitly set to false would mean two different things). I have to think about this a bit to convince myself that the message is clear enough and useful for those this updated behaviour is trying to help. After reading the above message three times, I still cannot shake the impression that we are just covering our backside to be able to say "we told you already and you chose poorly", in case things go wrong for them later. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
