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