Re: first parent, commit graph layout, and pull merge direction

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2013, 22:11 UTC
Message-ID: <7vli75cpom.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130523215557.GX27005@serenity.lan>

John Keeping <john@keeping.me.uk> writes:

Show 6 quoted lines

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