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

From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: John Keeping <john@keeping.me.uk>, Andreas Krey <a.krey@gmx.de>,
	John Szakmeister <john@szakmeister.net>,
	git@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: first parent, commit graph layout, and pull merge direction
Date: Thu, 23 May 2013 15:54:03 -0700	[thread overview]
Message-ID: <7v8v35cnp0.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAMP44s3-3gpAAyp-WfDjHxJiotO68GUbb5tHw9Qo35yCTGFNqA@mail.gmail.com> (Felipe Contreras's message of "Thu, 23 May 2013 17:46:19 -0500")

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 ;-).