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 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, or just 'git pull --merge', or 'git fetch'+'git merge' (we should make merge.defaulttoupstream=true as well). > 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. It is also my experience that most people don't do 'git pull', because it rarely does what one wants; 'upstream' is still too cumbersome for most people. > Also "rebase" of the branch you attempted to push out is sometimes a > good solution (fixing "just a small change on 'master'" that was > beaten by somebody else pushing first), but is a bad workaround (you > had many changes on that branch, which would have been better if > they were done on a topic branch, but you do not want to merge with > the upstream because you worked on 'master') some other times, so I > have this suspicion that 'pull.rebase' is not necessarily a good > thing to encourage in the first place. Too bad, that's what most people recommend; 'git fetch'+'git rebase'. That's the only way newcomers can avoid the ugliness of 'upstream', and avoid making atrocious merges. It's silly that the people familiar with Git has to explain this to each and every newcomer. -- 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
