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

On Thursday 07 December 2006 04:44, Junio C Hamano wrote:

Josef Weidendorfer [off-list ref] writes:

quoted

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

We could setup the branch.*.remote option for every tracking branch
git-clone is fetching (and git-fetch with the wildcard refspec).
And git-branch sets branch.*.remote/merge for the new branch
whenever it sees that a remote is set for the branch we are
branching off.
 

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

I see.
But I hope with my suggestion above, this can be looked up then
in the branch."remotes/origin/for-public".remote option.