Re: Terminology question about remote branches.

[David Kastrup <dak@gnu.org>]

Sean <seanlkml@sympatico.ca> writes:

> On Sat, 04 Aug 2007 16:01:55 +0200
> David Kastrup <dak@gnu.org> wrote:
>
>> 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