Shawn Pearce [off-list ref] writes:
I didn't want to use refs/notes/bad-commits because its not really an
annotation you would be looking at with git log.
Why not? Within a repository with bad commits, you would want an option
to have them applied to bad commits you still have, no?
I am still torn with this patch, and I say "still" for a reason. Even
though notes are implemented as commits, they are not commits on a part of
normal histories, and restriction of them within refs/notes hierarchy at
least is a safety measure (it is easy to loosen a restriction later, but
it is hard to let people loose first and then later restrict). While a
purist in me says that GIT_NOTES_REF and command line option _should_
enforce the same restriction, keeping the more obscure GIT_NOTES_REF
interface a bit looser gives us an escape hatch.
As to remote interface, refs/remotes/$remotes/ hierarchy corresponds to
the local refs/heads/ interface, so I do not think we will change the
default mapping we document (and have "clone" prepare) to place notes
obtained from elsewhere in refs/remotes/ hierarchy (we do not do that for
tags neither), so I think Johan's point is an independent issue.
On Tuesday 02 November 2010, Junio C Hamano wrote:
As to remote interface, refs/remotes/$remotes/ hierarchy corresponds to
the local refs/heads/ interface, so I do not think we will change the
default mapping we document (and have "clone" prepare) to place notes
obtained from elsewhere in refs/remotes/ hierarchy (we do not do that for
tags neither), so I think Johan's point is an independent issue.
I assume that means you'd rather have remote-tracking notes refs live under
refs/notes. So, to avoid collisions with local notes refs (and remote-
tracking notes refs from _other_ remote), we probably want to store them
under refs/notes/remotes/$remote/. I have no problem with that.
Although I'm starting to wonder whether our remote -> local refspec mappings
are getting too varied (i.e. confusing). Currently we have:
Remote repo -> Local repo
------------------------------------------------
refs/heads/* refs/remotes/$remote/*
refs/tags/* refs/tags/*
...and soon we may also have:
refs/notes/* refs/notes/remotes/$remote/*
Of these, the first is specified in the config, the second is
implicit/magic, and the third would be specified in the config.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
Johan Herland wrote:
Although I'm starting to wonder whether our remote -> local refspec mappings
are getting too varied (i.e. confusing). Currently we have:
Remote repo -> Local repo
------------------------------------------------
refs/heads/* refs/remotes/$remote/*
refs/tags/* refs/tags/*
...and soon we may also have:
refs/notes/* refs/notes/remotes/$remote/*
How about
refs/notes/* refs/notes/$remote/*
?
Plus side: shorter magic prefix to remember,
--notes-ref=charon/full would work with the
current --notes-ref dwimery.
Downside: potential for name conflicts?
Hi
Although I'm starting to wonder whether our remote -> local refspec
mappings
are getting too varied (i.e. confusing). Currently we have:
Remote repo -> Local repo
------------------------------------------------
refs/heads/* refs/remotes/$remote/*
refs/tags/* refs/tags/*
What's the rationale for the implicit/magic behaviour for tags? It
causes plenty of confusion for new users, etc.
-- Chris Forbes