On Friday 11 February 2011, Jakub Narebski wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > - 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". > > - Lack of consistency in which fetch refspecs must be listed in the > > configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal > > tries to address this as well. > > Could you repeat your proposal? http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885 > 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/* > Perhaps with > > fetch = +refs/heads/*:refs/remotes/origin/heads/* FTR, my new/proposed 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/heads* fetch = ~+refs/tags/*:refs/remotes/origin/tags/* ( fetch = +refs/notes/*:refs/remotes/origin/notes/* ) ( fetch = +refs/replace/*:refs/remotes/origin/replace/* ) > > - 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 inconsisnency 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. Have fun! :) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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