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

[Jeff King <peff@peff.net>]

On Sun, Apr 05, 2009 at 10:28:02PM -0700, Junio C Hamano wrote:

> > 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):
> 
> I think that is a sane approach, but isn't "tracking" a misnomer?  I think
> what you are describing is what is called "the upstream branch" by the
> description of Documentation/config.txt::branch.<name>.merge, and not what
> people call "tracking branch" (see Documentation/glossary-content.txt).

I think this is the classic "both of these concepts are called
tracking and it is confusing" that people complain about from time to
time. This is the value created by "--track", and most of the internal
functions call it that (e.g., stat_tracking_info, fill_tracking_info,
etc).

But I am happy to call it something else if it will reduce confusion.
"upstream" is a fine name, I think (though that is often referring to
the upstream _repository_, so maybe somebody might expect it to print
"origin" here).

> I also wonder if you want to say "this remote" and "that branch"
> separately.  As far as I can tell you are not giving the former but only
> the latter information?

Well, I don't think they are two separate parts. "that branch" has
already used information about the remote to reach its answer, and is
self-contained. It's all you need to know to do any non-fetching
operations (like seeing how your commits compare with upstream's, for
example).

Which isn't to say "this remote" might not be interesting. But I think
that is somewhat independent of this value, and moreover, it is already
trivial to find via "branch.*.remote" (or are there lookup rules I am
forgetting about?). The point of this exercise was that it is very
tricky to do the "upstream" correctly, so exposing the C code makes
sense.

-Peff