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 5:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>> John Keeping <john@xxxxxxxxxxxxx> 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
--
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]