Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone

From: Junio C Hamano <junkio@cox.net>
Date: Dec 7, 2006, 03:44 UTC
Message-ID: <7v64cowers.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200612070349.58521.Josef.Weidendorfer@gmx.de>

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> IMHO there only should be one place/command which is creating new branches,
> and which is called by other porcelain commands [*1*].

Giving an option to git branch to set something like this up would be nice. I would agree the division of labor you propose is a good way to keep the scripts maintainable.

It however is a different matter if we would want to set up the merge default always in the way you propose for a new branch at the policy level.

It also is a different matter if "git branch" has enough information to figure out which upstream "origin" needs to be fetched from, given an origin SHA-1 expression to create a new branch from, at the technical level

It entirely is possible to use the same remotes/origin/ hierarchy to track two physically different URLs (thus two different "origin"s) on a mobile machine that has different connectivity to the outside world depending on where you are ("that mirror is closer from here" and "I need to go over the firewall while I am here"). Because they track the logically same repository, it does not make sense to use different hierarchies under remotes/ for this purpose.

In such a setup, "git branch new origin/for-public" would not be able to tell which "origin" to fetch from, so it may not even be feasible to do what you propose without an explicit help from the command line option. At least, however, the call to "git branch" you would add as a part of this proposal to "git clone" would know which URL, because at that point it would not even know about the alternate connectivity yet.

> Why should we not setup branch.*.merge when a create a new development
> branch from a tracking branch via "git branch", or "git checkout -b"?

So while I am definitely in favor of the technical side of your proposal to have "git checkout -b" use "git branch", instead of doing it by hand, I think it would be an easier sell to separate the policy from the discussion at least in the beginning.

I say this not because I disagree with your question: "Why should we not?" I do not have a ready-answer to that rhetorical question yet. But that is different from saying "it does not make sense to do this setup because of such and such concrete reasons", so I haven't formed an opinion on this policy matter yet.