"remote-tracking branch"?

Marc Branchaud· Jun 11, 2012, 14:54 UTC · lore

On 12-06-11 06:04 AM, Lucien Kong wrote:

Show 5 quoted lines

> "git rebase -i" can be very dangerous if used on an already published
> history. This code detects that one is rewriting a commit that is an
> ancestor of a remote-tracking branch, and warns the user through the
> editor. This feature is controlled by a new config key
> rebase.checkremoterefs.

When I first read this I was confused by the term "remote-tracking branch". I see that the docs for "git remote" and "git branch" use this term for branches like 'origin/master', as does the glossary.

But to me 'origin/master' is simply a "remote branch".  In my mind, a
"remote-tracking branch" is a local branch with its "remote" and "merge"
config values set.  So if my local config has
	branch.public.remote = origin
	branch.public.merge = refs/heads/master
then my local 'public' branch is a "remote-tracking branch" that tracks the
'master' branch in the 'origin' repository.

I feel my interpretation is reinforced by the --track/--no-track options in "git branch".

I believe the docs would be clearer if they used the terms "remote branch" and "remote-tracking branch" in this way.[1] But before submitting a patch, I'd like to hear what others think. Am I maybe missing some other interpretation of "remote branch"? Or is there already a term for "a local branch that tracks a remote branch"?

M.

[1] I understand that strictly speaking, all branches are local, and a "remote branch" like 'origin/master' is in fact a local branch named 'master' in the 'origin' namespace, and that it's really the fetch refspecs in a remote's configuration that link updates in a remote repository to some local branches, and there's no requirement that a remote named 'origin' be linked with the local 'origin' ref namespace, and so on and so on. I think these details are important, and should be documented somewhere. But I also think "remote branch" is a good shorthand term to refer to all that.

Junio C Hamano· Jun 11, 2012, 16:31 UTC · re: Marc Branchaud · lore

Re: "remote-tracking branch"?

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 6 quoted lines

> When I first read this I was confused by the term "remote-tracking branch".
> I see that the docs for "git remote" and "git branch" use this term for
> branches like 'origin/master', as does the glossary.
> ...
> I feel my interpretation is reinforced by the --track/--no-track options in
> "git branch".

They were added long after "remote tracking branch" terminology has been established to mean the copies of last observed values of refs at remotes, and back then nobody noticed that these misnamed options were potential sources of this kind of confusion. If anything, these options need to be renamed if you want to avoid confusion.

Unfortunately, no concensus terminology for them exist; I find myself calling them "the branch you integrate with upstream's master", "the branch you forked from origin's topic", etc.

Junio C Hamano· Jun 11, 2012, 16:46 UTC · re: Junio C Hamano · lore

Re: "remote-tracking branch"?

Junio C Hamano <gitster@pobox.com> writes:

> Unfortunately, no concensus terminology for them exist; I find
> myself calling them "the branch you integrate with upstream's
> master", "the branch you forked from origin's topic", etc.

Actually, I take that "no concensus exists" back. "upstream" is probably the closest to the consensus terminology, and that is why "git log master@{upstream}" will give you the history of the remote tracking branch you use to integrate with master.