Re: [PATCH] Remove restriction on notes ref base

From: Johan Herland <johan@herland.net>
Date: Nov 4, 2010, 00:49 UTC
Message-ID: <201011040149.47968.johan@herland.net>
In-Reply-To: <AANLkTin_NuzQocOab+w=B3Ka+n22j2-OXQu8=J6uzByS@mail.gmail.com>

On Wednesday 03 November 2010, Sverre Rabbelier wrote:

Show 9 quoted lines

> 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