Re: [PATCH] Remove restriction on notes ref base

[Johan Herland <johan@herland.net>]

On Wednesday 03 November 2010, Sverre Rabbelier wrote:
> On Wed, Nov 3, 2010 at 17:17, Junio C Hamano <gitster@pobox.com> wrote:
> > I was actually thinking more along the lines of "not keeping track of
> > remote state at all".  We don't do that for tags either.
> 
> I would rather see us go the other way (and make the tags refspec put
> tags under refs/tags/remotes/.../). I can understand not scoping tags
> (since they're supposed to be immutable, and are usually global), but
> I don't think the same holds for notes. Notes _are_ versioned, and
> it's expected that users will collaborate.

Agreed. I don't see how you can easily share and manipulate notes between 
repos _without_ keeping the remote state separate from the local state.


I'm probably gonna be flamed for this, but I'd like to go even further, and 
- for a future major version of Git - reconsider Git's default refspecs. 
Currently we have:

  Remote repo    ->   Local repo
  ------------------------------------------------
  refs/heads/*        refs/remotes/$remote/*
  refs/tags/*         refs/tags/*
  refs/notes/*        ???

Of these, the first is specified in the config, the second is 
implicit/magic, and the third would be specified in the config.

I'd probably suggest a more straightforward (and hopefully less confusing) 
setup like this:

  Remote repo    ->   Local repo
  ------------------------------------------------
  refs/heads/*        refs/remotes/$remote/heads/*
  refs/tags/*         refs/remotes/$remote/tags/*
  refs/notes/*        refs/remotes/$remote/notes/*

...and these would all be set in the config, i.e. no implicit/magic 
refspecs.

Now, there would obviously need to be some accompanying changes:

We would, for example, extend the ref disambiguation of <name> (as 
documented in the "SPECIFYING REVISIONS" section of git-rev-parse(1)), so 
that in the cases where <name> is of the form "<foo>/<bar>" AND <foo> is an 
existing remote, we also check for the following refs (after none of the 
existing checks have returned a match):

  7. refs/remotes/<foo>/tags/<bar>
  8. refs/remotes/<foo>/heads/<bar>

We would also need similar disambiguation rules for notes refs, e.g.:

  1. $GIT_DIR/<name>
  2. refs/notes/<name>
  3. refs/remotes/<foo>/notes/<bar> (when <name> is of the form <foo>/<bar>)

With these rules, we could use "origin/master", "origin/v1.2.3" and 
"origin/bugnotes" to refer to "refs/remotes/origin/heads/master", 
"refs/remotes/origin/tags/v1.2.3" and "refs/remotes/origin/notes/bugnotes" 
respectively.

As a bonus, we'd get better handling of conflicting tag names: If e.g. 
remotes "alice" and "bob" each have a tag "xyzzy" pointing to different 
objects, you could reference and compare both tags (using "alice/xyzzy" and 
"bob/xyzzy", respectively), and optionally set your own local tag 
("refs/tags/xyzzy") to match either of them.


...Johan (scrambles for a flame retardant suit)


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