Heya, On Fri, Oct 22, 2010 at 10:41, Johan Herland <johan@xxxxxxxxxxx> wrote: > Yes, sorry for not answering you earlier. Here's what you wrote in the > previous thread: No problem :). > On Saturday 09 October 2010, Sverre Rabbelier wrote: >> On Sat, Oct 9, 2010 at 03:08, Johan Herland <johan@xxxxxxxxxxx> 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. >> > Â- 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. > 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? >> > Â- 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. > 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. -- Cheers, Sverre Rabbelier -- 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