On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> John Keeping <j...@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
> 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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html