Re: [PATCHv4 00/21] git notes merge

[Johan Herland <johan@herland.net>]

On Friday 22 October 2010, Sverre Rabbelier wrote:
> On Fri, Oct 22, 2010 at 10:41, Johan Herland wrote:
> > On Saturday 09 October 2010, Sverre Rabbelier wrote:
> >> On Sat, Oct 9, 2010 at 03:08, Johan Herland wrote:
> >> > - Fetching and pushing note refs:
> >> >  - Add refs/notes/* to default fetch refspec?
> >> 
> >> Or at least add a '--notes[=<notes namespace>]' to fetch, pull, and
> >> push.
> > 
> > Agreed, at least that.
> > 
> > In order to promote sharing of notes, though, I'd like for it to be
> > possible to configure the repo so that a vanilla 'git fetch' also
> > updates your notes. In fact, I wonder if this should even be made the
> > default.
> 
> I think notes directly under /refs/notes/ should be shared by default,
> but those in sub-refs (such as the /refs/notes/am/ that's been
> mentioned before) should not.

In theory that would make sense, but how you write that as a refspec? AFAIK, 
refspecs don't (yet) support a syntax for (a) _excluding_ something from a 
glob, and certainly not (b) excluding all "sub-refs" from a glob.

Alternatively, we could share everything under refs/notes/, except 
/refs/notes/local/ (or refs/notes/private/ or whatever). That would just 
require support for (a)...

> >> >  - A way to specify (at clone time) which refspec(s) to set up?
> >> 
> >> How would that look like?
> > 
> > Maybe add an option to 'git clone' (and 'git remote add') that
> > specifies the refspec you want to use in your config for that remote.
> > Something like:
> > 
> >  git clone --fetch="+refs/heads/*:refs/remotes/origin/*" \
> >            --fetch="+refs/notes/*:refs/remotes/origin/notes/*" \
> >            <source_url> ...
> 
> Who's going to type that out though? The only use case I can think of
> is if you want to be able to give someone a line they can paste and be
> set right away, but I don't see why in that case pasting multiple
> commands (i.e., calling 'git config' a few times) wouldn't suffice.

You might be right. I was thinking that before we provide shorthands, we 
should provide an option that let you specify _any_ refspec. Sort of as a 
fallback if somebody's scenario doesn't fit into any of the shorthands.

But as you say, this can also be done with a few calls to git config.

> > Obviously, we would probably want to provide shorthands for the most
> > common refspecs, like:
> > 
> >  git clone --fetch=default,notes <source_url> ...
> >  git clone --fetch-heads --fetch-notes <source_url> ...
> 
> Adding refspec shorthands _does_ make sense. However, it might make
> more sense to put those under 'git remote' instead?

I'd say _both_ 'git remote' and 'git clone'.

> >> >  - A way for the remote repo to hint at which refspecs you might
> >> > want to set up (by default?)
> >> 
> >> I assume this would be a generic mechanism of sorts? Are there any
> >> other use cases for this other than notes?
> > 
> > Yes, I believe so (although I haven't thought much about this, yet).
> > There's been earlier discussions on hiding certain branches from view.
> > This could maybe be solved by the server suggesting a refspec that
> > excludes the stuff you don't want to share (by default). Similary, the
> > refspec could _include_ notes namespaces that you do want to share.
> 
> That sounds like a good use case.

But I believe we need to extend the refspec syntax to support at least (a) 
from above (excluding named entries from a refspec glob) in order to support 
hiding of certain refs. Still, I think it would be a useful addition.

> > Of course (as today) the client should be free to demand a different
> > refspec, e.g. if it wants access to everything, or if it's only
> > interested in a subset of the "default" refs.
> 
> Of course, I reckon it would just set up their refspecs, and the user
> would be free to change it. Especially if we inform the user that the
> refspec was set to something other than the default refspec.

Agreed.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net