On Aug 5, 2007, at 9:31 AM, Junio C Hamano wrote:

quoted text
> David Kastrup <dak@gnu.org> 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.

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.


quoted text
> 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



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html