Sean <seanlkml@xxxxxxxxxxxx> writes: > On Sat, 04 Aug 2007 16:01:55 +0200 > David Kastrup <dak@xxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
