Re: first parent, commit graph layout, and pull merge direction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]