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

Johan Herland [off-list ref] 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.

quoted

quoted

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