On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano <gits...@pobox.com> wrote: > > If the proposal were to make pull.rebase the default at a major > version bump and force all integrators and other people who are > happy with how "pull = fetch + merge" (not "fetch + rebase") works > to say "pull.rebase = false" in their configuration, I think I can > see why some people may think it makes sense, though. > > But neither is an easy sell, I would imagine. It is not about > passing me, but about not hurting users like kernel folks we > accumulated over 7-8 years.
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. Linus -- 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