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
