Santi Béjar <santi@xxxxxxxxxxx> writes:
> One thing it just occurred to me is to return the explicit refspec
> instead of the tracking branch. So with the default config (after a
> clone):
>
> $ git remote tracking origin refs/heads/master
> refs/heads/master:refs/remotes/origin/master
I think the output is sensible, instead of saying something like
'origin/master'.
We can and should allow the end users to use abbreviated form as input to
us (either command line or configuration value) when it is unambiguous,
but when returning values for use by Porcelains, we should be strict and
precise to avoid ambiguities.
> this makes a difference in case we want to allow returning all the
> matching tracking branch and not the first one with more than one
> branch, as:
>
> $ git config remote.origin.fetch --add +refs/heads/*:refs/remote/another/*
>
> $ git remote tracking origin refs/heads/master
> refs/heads/master:refs/remotes/origin/master
> refs/heads/next:refs/remotes/origin/next
I am not sure what this example is doing. You asked about refs/heads/master
but you also talk about refs/heads/next? I guess you meant to say
$ git remote tracking origin refs/heads/master
refs/heads/master:refs/remotes/origin/master
refs/heads/master:refs/remotes/another/master
instead, judging from the next example?
> $ git remote tracking origin refs/heads/master refs/heads/next
> refs/heads/master:refs/remotes/origin/master
> refs/heads/master:refs/remotes/another/master
> refs/heads/next:refs/remotes/origin/next
> refs/heads/next:refs/remotes/another/next
--
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