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