Re: [PATCHv4 00/21] git notes merge

On Friday 22 October 2010, Sverre Rabbelier wrote:

On Fri, Oct 22, 2010 at 10:41, Johan Herland wrote:

quoted

On Saturday 09 October 2010, Sverre Rabbelier wrote:

quoted

On Sat, Oct 9, 2010 at 03:08, Johan Herland wrote:

quoted

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

quoted

quoted

quoted

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

quoted

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

quoted

quoted

quoted

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

quoted

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, [off-list ref]
www.herland.net