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 >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
