Re: Terminology question about remote branches.
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 4, 2007, 15:22 UTC
- Message-ID
- <85k5sbfhnw.fsf@lola.goethe.zz>
- In-Reply-To
- <20070804104851.162d7e00.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
Show 8 quoted lines
> 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.
Show 17 quoted lines
> 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