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

From: Jeff King <peff@peff.net>
Date: Apr 6, 2009, 05:49 UTC
Message-ID: <20090406054920.GA19214@coredump.intra.peff.net>
In-Reply-To: <7vy6uecpwd.fsf@gitster.siamese.dyndns.org>

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

Show 8 quoted lines

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