Re: Re* [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano <gitster@pobox.com>]

Johan Herland <johan@herland.net> writes:

> On Monday 14 February 2011, Junio C Hamano wrote:
> ...
> For the foreseeable future (i.e. long after v1.8.0 is out) we will still 
> have to understand and support the traditional "tags are implicitly 
> auto-followed" and "tags live in a single global namespace" concepts 
> (aka. (a) below). For new-style remotes I propose that all refspecs be 
> explicit, and that auto-follow is disabled (aka. (b) below).
>
> But if you try to specify a new-style remote with all tags in a single 
> global namespace, you will NOT get tag autofollowing (aka. (c) below)

Ok.

> (Note that if we cannot reliably detect the difference between old-style 
> (implicit) and new-style (explicit) remotes, we will likely have to add 
> a boolean flag, e.g. "remote.origin.implicitTagFollowing".)

Ok.

>> > ... However, what I've seen at $dayjob is
>> > that more inexperienced users will often push right after
>> > committing, and at that time they're still very much in the
>> > "working-on-one-branch" state of mind (as opposed to the
>> > "administering-multiple-branches" state of mind),...
>>
>> Then "current" mode is a good setting for them, I would presume.
>
> Arguably in some workflows, 'tracking' may be a more suitable default 
> (i.e. safer for newbies) than 'current', but in practice this shouldn't 
> matter much (local branch names usually correspond to remote branch 
> names).

Of course you are right.  The "this pulls from there, and pushes back
to the same place" model was what I had in mind when I wrote the patch; 
I just was confused between the "tracking" vs "current" labels.

> Offtopic PS: Given that we're leaning towards using 'tracking' to 
> describe the relationship between remote-tracking branches 
> (refs/remotes/*) and remote branches, and 'upstream' to describe the 
> relationship between a local branch and the remote branch it 
> follows/merges (on 'git pull'), wouldn't
>
>   push.default == "upstream"
>
> be more descriptive than
>
>   push.default == "tracking"

"Local Branch" and "Remote Tracking Branch", both of which physically
reside on the local end of the communication and are tied by their
"merge/rebase" relationship, are much more distinct than "Remote Branch"
and "Remote Tracking Branch" that are tied by their "fetch" relationship.
A remote tracking branch is a mere (time-lagged) mirror of the remote
branch it tracks, and mental distance between them is much smaller than
that of between a local branch and its @{upstream} that is a remote
tracking branch.  Conceptually the _true_ upstream of a local branch is
the remote branch from which its @{upstream} remote tracking branch copies
from.

So in that sense, I agree "pushing my change to the upstream" would match
the mental model of an end user somewhat better than "pushing my change
back to what I track".

Perhaps leave "tracking" as a deprecated synonym and add "upstream" as the
official name of the mode?