Re: [1.8.0] Provide proper remote ref namespaces

> > > - Lack of consistency in the ref namespace (refs/remotes/$remote/* vs.
> > > refs/tags/*). Also not clear from the current layout where to add new
> > > types of refs (e.g. notes, replace). My proposal tries to address this
> > > issue.
> > 
> > The lack of consistency is there because tags should USUALLY be global
> > (there should be only one v1.7.4), while branch names should be local
> > (my 'master' branch is not your 'master' branch).
> >
> > In some cases, like joining or subtree-merging unrelated projects we
> > would want local / per-remote tags: 'v1.7.4' in main project is not
> > 'v1.7.4' in 'foo' subproject (in 'foo' remote).  Currently we lack a
> > way to specify that (the 'autofollow' refspec proposal, default
> > behaviour would be equivalent to '~refs/tags/*:refs/tags/*"), and lack
> > support from porcelain: MY PROPOSAL is to add '--use-separate-tags'
> > (like old '--use-separate-remote') to "git clone" and "git remote add",
> > and perhaps '--alternate' as equivalent to '--no-separate-tags' to
> > "git remote add".
> 
> That requires you to know about the (potential) tag collision (and remember 
> to use your option) before fetching from the remote repo.

> Also, even with your added option - which we can use when interfacing 
> unrelated projects from a single repo - the expectation (common case) is 
> still that Git will pollute your local tag namespace with remote tags. Some 
> of us consider this a bug/misfeature in its own right. And we hold that 
> opinion while still agreeing with you that tags "should USUALLY be global".

> > Do I remember it correctly that with
> > 'autofollow' refspec (valid only for tags... well, perhaps also for
> > notes and replacements) you want to specify defaults in config
> > explicitely
> > 
> >   [remote "origin"]
> >         url = git://git.example.com/repo.git
> >         fetch = +refs/heads/*:refs/remotes/origin/*
> >         fetch = ~refs/tags/*:refs/tags/*
> 
> Yes, replicating existing behavior w/explicit refspecs would look like this:
> 
>   [remote "origin"]
>         url = git://git.example.com/repo.git
>         fetch = +HEAD:refs/remotes/origin/HEAD
>         fetch = +refs/heads/*:refs/remotes/origin/*
>         fetch = ~refs/tags/*:refs/tags/*

> > > - Lack of consistency in porcelain interfaces. Some of these have been
> > > fixed in recent Git version, but some are yet to be fixed: E.g. some
> > > find the use of FETCH_HEAD confusing (when does fetch update the
> > > remote refs, and when does it update FETCH_HEAD instead?).
> > 
> > One of problems is how to keep the fact that
> > 
> >   $ git pull <URL> <branch>
> > 
> > does one-off pull without creating remote or remote-tracking branch.
> > But I agree that behavior of
> > 
> >   $ git pull <remote> <branch>
> > 
> > can be confusing.
> 
> Yes, to me it seems intuitive that when you specify <URL> (even if <URL> 
> corresponds to an existing remote) you do NOT update remote-tracking refs, 
> but if you use <remote>, you should ALWAYS update remote-tracking refs. 
> Others may disagree.

> > >  Others (myself included) wonder why 'git push' by default updates
> > > 
> > > remote branches with matching names, while 'git pull' relies on the
> > > explicitly configured upstreams to update the local refs. (FWIW,
> > > I've mitigated this last complaint insisting that all users at
> > > $dayjob run "git config --global push.default tracking" immediately
> > > after installing Git.) There are other UI inconsistencies too that
> > > escape me ATM.
> > 
> > IMHO that's not inconsistency in Git, this is just reflection of the
> > fact that in most common case the situation is *assymetric* with
> > respect to fetch and push; you fetch from other people repositories,
> > but you push to (usually single, perhaps mirrored) your own publishing
> > repository.  For this situation 'push.default = matching' works
> > perfectly.
> 
> It may seem so, but in my experience it doesn't really work perfectly: Even 
> if I fully control the repo I push to, I still want precise control over 
> what I push there. Sometimes I may working on 'next' and 'master' in 
> parallel, and I might have finished and tested some bugfixes on 'master', 
> while I still have unfinished/untested stuff on 'next'. When I 'git push' 
> from 'master', I DO NOT want 'next' to be pushed (unless I have explicitly 
> asked for it).

> If I'm pushing to a shared repo (a very common workplace setup), this 
> default is even more potentially damaging (especially if I don't discover 
> what's actually happening by scanning the output from 'git push').
> 
> This is one area where Git's current default behavior is less conservative 
> than I would like.