David Kastrup [off-list ref] writes:
I am trying to dig through man-pages and user manual and trying to
match them with reality. I seem to have a hard time. My current
understanding (which definitely differs from the documented state) is
that there are two types of branches, local and remote branches, and
both types of branches can be remote-tracking (it may not be possible
to have a non-remote-tracking remote branch, though).
I think we have a brief discussion on #git before you brought
this up ;-)
- local branches -- we know what they are.
- remote tracking branches -- refs that appear in refs/remotes/
in the current world order; they are updated only by copying
the corresponding local branches at the remote site, and are
meant to "keep track of what _they_ are doing". In olden
days before 1.5.0 with non separate remote layout,
'refs/heads/origin' branch, and all the non default branches,
were treated this way as well. You were not supposed to make
commit on them (because of the above "keep track of" reason),
and having them under refs/heads were too confusing, which
was the reason the separate remote layout was invented.
You can have a local branch that is created by forking off of a
remote tracking branch, with the intention to "build on top" of
the corresponding remote tracking brach. You can create such a
branch and mark it as such with --track option introduced in
v1.5.1 timeperiod. This is a relatively new concept, but many
people find it useful. We do not have the official term to call
this concept, and some people have misused the term "remote
tracking branches" to describe this, which made things very
confusing.
We would need an official terminology for it.
On Aug 5, 2007, at 9:31 AM, Junio C Hamano wrote:
David Kastrup [off-list ref] writes:
quoted
I am trying to dig through man-pages and user manual and trying to
match them with reality. I seem to have a hard time. My current
understanding (which definitely differs from the documented state) is
that there are two types of branches, local and remote branches, and
both types of branches can be remote-tracking (it may not be possible
to have a non-remote-tracking remote branch, though).
I think we have a brief discussion on #git before you brought
this up ;-)
- local branches -- we know what they are.
- remote tracking branches -- refs that appear in refs/remotes/
in the current world order; they are updated only by copying
the corresponding local branches at the remote site, and are
meant to "keep track of what _they_ are doing". In olden
days before 1.5.0 with non separate remote layout,
'refs/heads/origin' branch, and all the non default branches,
were treated this way as well. You were not supposed to make
commit on them (because of the above "keep track of" reason),
and having them under refs/heads were too confusing, which
was the reason the separate remote layout was invented.
The current user manual defines this case in the glossary as
'tracking branch' (without remote), but mostly uses
'remote-tracking branch' at other places. Tracking branch
and remote-tracking branch seem to be equivalent. And I think
we should leave it this way.
You can have a local branch that is created by forking off of a
remote tracking branch, with the intention to "build on top" of
the corresponding remote tracking brach. You can create such a
branch and mark it as such with --track option introduced in
v1.5.1 timeperiod. This is a relatively new concept, but many
people find it useful. We do not have the official term to call
this concept, and some people have misused the term "remote
tracking branches" to describe this, which made things very
confusing.
We would need an official terminology for it.
Something like 'automerging branch', and replace options with
'--automerge/--no-automerge'?
I'm not fully convinced of this idea because it may be
technically correct but doesn't really reflect the intention of
'building on top' of the remote tracking branch.
Steffen
On Sun, 5 Aug 2007, Junio C Hamano wrote:
David Kastrup [off-list ref] writes:
quoted
I am trying to dig through man-pages and user manual and trying to
match them with reality. I seem to have a hard time. My current
understanding (which definitely differs from the documented state) is
that there are two types of branches, local and remote branches, and
both types of branches can be remote-tracking (it may not be possible
to have a non-remote-tracking remote branch, though).
I think we have a brief discussion on #git before you brought
this up ;-)
- local branches -- we know what they are.
- remote tracking branches -- refs that appear in refs/remotes/
in the current world order; they are updated only by copying
the corresponding local branches at the remote site, and are
meant to "keep track of what _they_ are doing". In olden
days before 1.5.0 with non separate remote layout,
'refs/heads/origin' branch, and all the non default branches,
were treated this way as well. You were not supposed to make
commit on them (because of the above "keep track of" reason),
and having them under refs/heads were too confusing, which
was the reason the separate remote layout was invented.
You can have a local branch that is created by forking off of a
remote tracking branch, with the intention to "build on top" of
the corresponding remote tracking brach. You can create such a
branch and mark it as such with --track option introduced in
v1.5.1 timeperiod. This is a relatively new concept, but many
people find it useful. We do not have the official term to call
this concept, and some people have misused the term "remote
tracking branches" to describe this, which made things very
confusing.
We would need an official terminology for it.
Following was mentioned earlier in this thread ... could we use that?
tracking branch:
ref always points at a commit from the remote repo branch
following branch:
ref either points at a commit from the remote repo branch, or a
local commit with a commit from the remote repo branch in the history
perhaps?
--
Julian
---
An optimist is a man who looks forward to marriage.
A pessimist is a married optimist.