Re: Terminology question about remote branches.

Sean [off-list ref] writes:

On Sat, 04 Aug 2007 16:01:55 +0200
David Kastrup [off-list ref] wrote:

quoted

So --track does not set up a tracking branch, but makes a local
_following_ branch _refer_ to a tracking branch.

Sure, that's one way to describe it; perhaps it would be best if
we switched to that nomenclature in the documentation.

Not according to my current understanding, but that can, of course,
change again in the next few hours.  As far as I understand right now,
such a branch indeed tracks a remote branch (and not a remote tracking
branch), it just does not track it recklessly: it has a head of its
own, and it won't use git-fetch -f for updating it.

It's not a problem, you could just add an appropriate [branch...] section
in your .git/config.   Actually looking at a typical branch section
is even more confusing to me:

    $ git branch fudge origin/fix1

adds this to the .git/config:

    [branch "fudge"]
        remote = origin
        merge = refs/heads/fix1

The config file does not record the remote-tracking-branch, instead
it explicitly records the remote repository information.  So it sure
appears that if you add the --track option, it _does_ make the local
branch track a remote directly.  Thus it's hard to call it anything
but what you labelled it, a local tracking-branch.

Yes, it seems --track does track after all.  Just more cautiously than
a remote tracking branch does.

While I thought i had a handle on this, i'm now officially more
confused than you;

Good.  It means that I may not be a complete idiot.  It may also mean
that the documentation can be improved in places.  With a lot of
"grep" and fine-combing I realized that quite a bit of the information
_is_ "available" (and some conflicting information as well).

This is one reason why I would prefer to have something like a typical
Texinfo manual, at least on the organisational level: a manual is
supposed to present a single connected view to the available
documentation.  And the information for git is scattered through a
bunch of mostly disconnected files.

If you want to see a more staggering example of this approach, take a
look at the "guilt" documentation.  It consists only of the man pages
for the individual commands, and then some few README-like files which
mostly say something like "guilt is just like quilt, or like
Mercurial's patch sets".  That's rather extreme as far as
user-accessible information goes.  git has a few more generally useful
files explaining underlying concepts, but they still are basically
thrown into one large self-service heap, not a coherent document.

hopefully someone with knowledge of the guts of Git will speak up.

I think I am slowly getting it, thanks to Lars and others.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum