Re: [question] how can i verify whether a local branch is tracking a remote branch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 6, 2009 at 6:34 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Sun, Apr 05, 2009 at 11:25:29PM +0200, Paolo Ciarrocchi wrote:
>
>> An example:
>> $ git clone -n URL temp
>> $ cd temp
>> $ git branch -r
>>   origin/master
>>   origin/foo
>>   Origin/bar
>> $ git checkout --track -b foo origin/foo
>>
>> Now, how can I know that foo is tracking origin/foo ?
>
> Doing it right is hard. You have to:
>
>  1. check branch.foo.merge and branch.foo.rebase; if no value, it is not
>     tracking anything; if it is, remember that value as $m
>
>  2. check branch.foo.remote for the remote name, $r
>
>  3. check the fetch refspecs for remote $r; these can come from
>     the config, or from .git/remotes/* files. Maybe even .git/branches
>     files; I don't even remember how those work.
>
>  4. find the refspec that fetches from $m; then find the matching
>     destination for that refspec. That is the tracking branch.
>
> E.g., in your example (and using a modern git):
>
>  1. $m is refs/heads/foo
>  2. $r is origin
>  3. The fetch refspec is in remote.origin.fetch, and is generally
>     "refs/heads/*:refs/remotes/origin/*"
>  4. So refs/heads/foo becomes refs/remotes/origin/foo.
>     refs/remotes/origin/foo is your tracking branch.
>
> Steps 1 and 2 are easy, but 3 and 4 are a bit nasty. You can fake it by
> assuming that "refs/heads/$m" on "$r" is always "refs/remotes/$r/$m",
> which is true for very vanilla setups.
>
> There is C code that does this, but there is not a good way of accessing
> it from the command-line. The best you can do is "git remote show
> origin", which on recent git versions should show something like:
>
>  ...
>  Local branches configured for 'git pull':
>    foo    merges with remote foo
>  ...
>
> But of course that implies that you already guessed the remote "origin".
> And it's not using plumbing, so it's not very suitable for scripts.
>
> I don't think it would be unreasonable to expose this functionality via
> "for-each-ref". Something like this (which would need cleanup,
> documentation, and perhaps a :short variant):

Jeff,
thank you very much for your prompt answers and for your patch.

I often act like a GIT "evangelist" trying to help friends and
colleagues in starting using GIT and one of the "complaint" I'm
getting is that people expect to get this information out of the
branch command.

I mean something like:
$ git branch
 * foo <-> origin/foo

What do you think?

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]