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

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>>> This isn't about "swap parents", it's about helping people realise that
>>> just "git pull" isn't necessarily the best thing for them to do, and
>>> that they may want --rebase.
>>>
>>> So I was asking if it would be sensible (possibly in Git 2.0) to make
>>> git-pull pass --ff-only to git-merge by default.
>>
>> Unless your primary user base is those who use Git as a deployment
>> tool to always follow along the tip of some external repository
>> without doing anything on your own on the branch you run your "git
>> pull" on, defaulting it to --ff-only does not make much sense to me.
>
> A lot of people do stuff, but the rebase it.

If I am parsing the above properly, I think that is only saying that
"pull --rebase" makes sense for people who do real work, which I am
not disagreeing.

>> 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.
>
> That makes perfect sense, because the people that are not familiar
> with Git more often than not end up making merges by mistake, and the
> ones that are familiar with it can easily configure it to do what they
> want

Yes, in theory.  The transition needs a major version bump, but it
is doable (with unknown level of resistance).

>> 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.
>
> I've worked in the Linux kernel, and in my experience the vast vast
> majority of kernel developers don't do merges; they send patches. It's
> only the lieutenants that might do that, and although there are a lot,
> they don't surpass the 200, and they most definitely know how to
> configure Git to do what they need. And even then, most of them don't
> do merges, but create a linear history for Linus to merge.
>
> So the only one who does really rely on merges is Linus, I think he
> would have no problems configuring Git.

That is not something I can agree or disagree without looping
somebody whose judgement I can trust from the kernel circle ;-).