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

From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.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 18:09:30 -0500	[thread overview]
Message-ID: <CAMP44s1N=xy2B-YkCLC67pX_EVqAziGWyN1qkrs0Sq=o2jL6Sw@mail.gmail.com> (raw)
In-Reply-To: <7v8v35cnp0.fsf@alter.siamese.dyndns.org>

On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

You claimed that 'git pull' (--ff-only) only makes sense if the
primary user-base doesn't do any work on it, but that's not true; they
can do a 'git rebase' after such pull (or a merge).

We don't have to assume our primary user-base wants to do full fledged
merges, in fact, such assumption would be wrong.

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

Isn't that what wer are discussing here?

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

See section 16) in Documentation/SubmittingPatches, notice how the
whole section is written with Linus in mind. Some maintainers do have
sub-maintainers that send pull requests to them, not Linus, but they
are the minority. But most definitely pull requests are not for the
general population (except in a few very rare exceptions maybe).

-- 
Felipe Contreras