"remote-tracking branch"?

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

"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.