Johan Herland <johan@xxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html