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