On Wednesday 03 November 2010, Sverre Rabbelier wrote:
> On Wed, Nov 3, 2010 at 17:17, Junio C Hamano <gitster@xxxxxxxxx> 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@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