On Thursday 07 December 2006 04:44, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> 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
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.
Josef
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html