Re: [1.8.0] Provide proper remote ref namespaces

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 14 Feb 2011, Johan Herland wrote:
> On Friday 11 February 2011, Jakub Narebski wrote:
> > Johan Herland <johan@herland.net> 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.

No, what you need to know at te point of adding remote with "git remote add"
is to know whether the repository is alternative / extra repository of the
same project (common tags), or whether it is separate project (separate
tags).

Which you should know at this point.
 
> 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".

I don't think the distinction is between local and per-remote tags.  It
is about local (your own) bookmarking tags versus global repository tags
(_not_ per-remote) for marking releases.

I guess that current layout might be not best, but per-remote tags isn't it
either, in my opinion.


Please consider this use case:

Let's assume that current maintainer steps aside for a bit, and new interim
temporary maintainer takes mantle.  One would add new remote _temporarily_,
but one would want for tags that temporary maintainer created to be as good
as tags from 'origin' remote... and not be deleted when you remove temp
remote and its remote-tracking branches.

[...]
> > 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/*

I'm not sure about HEAD refspec; we don't have one for transferring symrefs.
"git push <remote> HEAD" doesn't push HEAD ut the current branch.

[...]
> > > - 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.

I agree.  Keeping remote-tracking branches stale on purpose doesn't look
for me like a sane workflow.

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

Then do "git push <remote> HEAD" to push current branch only in this
*special case* (I think there was proposal to have "git push HEAD" to
push to default remote, but I don't know if it was accepted; well, this
idea can be resurrected if it isn't in).

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

I think that it would be good idea to have "git push --ask", which when on
terminal would present you with the list of branches that would be pushed,
and ask for confirmation if you push more than one branch or something
(or perhaps even "git push --interactive").

But this requires some discipline to *not* do work in progress on 
published branches (matching).

-- 
Jakub Narebski
Poland