"remote-tracking branch"?

"remote-tracking branch"?

[Marc Branchaud]

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.

Re: "remote-tracking branch"?

[Junio C Hamano]

Marc Branchaud <marcnarc@xiplink.com> writes:

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

Re: "remote-tracking branch"?

[Junio C Hamano]

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.