Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches

Santi Béjar [off-list ref] 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

2009/6/18 Junio C Hamano [off-list ref]:

Santi Béjar [off-list ref] writes:

quoted

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

OK.

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,

OK. Moreover I think it also applies to the %(upstream) case I
reported some days ago.

but when returning values for use by Porcelains, we should be strict and
precise to avoid ambiguities.

quoted

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?

Yes.

Santi