Re: Terminology question about remote branches.

From: Jeff King <peff@peff.net>
Date: Aug 5, 2007, 11:52 UTC
Message-ID: <20070805115208.GA19734@coredump.intra.peff.net>
In-Reply-To: <85tzre8b4w.fsf@lola.goethe.zz>

On Sun, Aug 05, 2007 at 01:38:07PM +0200, David Kastrup wrote:

Show 7 quoted lines

> > I believe the --track setup uses the tracking branches to figure out
> > which remote/branch combo to track. To do it without a remote tracking
> > branch, you would have to add the lines to your .git/config manually.
> 
> Fascinating, really fascinating.  Is there actually _anybody_ who
> would not revert to phrases like "I believe" when describing git's
> interaction with remote branches?

By "I believe", I meant "I am pretty sure this is the way it is implemented, but I have better things to do than read through builtin-branch.c right now, so please don't take this as gospel and go read the code yourself."

But the point of --track is that I don't _have_ to care, and that it deduces the correct remote/branch combination itself.

> I don't find this particularly logical: origin/something basically
> boils down referring to a commit.

Really, "origin/something" refers to "refs/remotes/origin/something", which we can deduce from the config to be populated by a particular remote and branch (go read the code).

> Maybe git-branch --track should allow referring to remote:branch or
> URLs or something directly rather than a remote tracking branch?

It could, but at that point, you could just do:

  git-branch newbranch oldbranch
  git-config branch.newbranch.remote someremote
  git-config branch.newbranch.merge remotebranch

Perhaps it's slightly more convenient to be able to do

  git-branch --track someremote:remotebranch newbranch oldbranch

but the real convenience of --track is when it deduces those parameters itself.

-Peff