From: Santi Béjar Date: Thu, 18 Jun 2009 21:31:51 GMT Subject: Re: [RFC/PATCH 1/2] remote tracking: return the tracking branch for the given branches Message-ID: In-Reply-To: <7v63etnydr.fsf@alter.siamese.dyndns.org> 2009/6/18 Junio C Hamano : > Santi Béjar 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'. 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. > >> 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