Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef

[Jeff King <peff@peff.net>]

On Wed, Sep 07, 2011 at 11:29:17PM +0200, Thomas Rast wrote:

> Admittedly I never considered the problem of supposedly-immutable
> notes here.  The whole point was to help users who had no idea that
> the string put there should probably start with refs/notes/.
> 
> So maybe the patch should instead say something along the lines of, to
> enable rewriting for the notes ref called foo, put refs/notes/foo --
> which to a core gitter of course sounds extremely redundant.
> 
> But what about the general issue of users who *have* put refs/notes/*,
> and then some software comes along that does not expect them to be
> rewritten?  Do we declare the software broken, or discourage from such
> blanket rewriting?

I think putting "refs/notes/*" is a perfectly reasonable thing from the
user's perspective, and I'd hate to take away that convenience (and
especially, I think in the long run, we'd like to have a hierarchy of
notes that have rewriting turned on by default).

The cache code is probably what should be changed, then. It can move to
"refs/cache", I guess, though I'm not too happy with that. The notes
code assumes refs/notes in several places, and it's nice to be able to
look at the cache trees with "--notes=cache/foo".

Maybe some way of saying "every notes tree gets rewriting, except ones
in refs/notes/cache"?

Right now it's not a big problem. The only such immutable cache in a
released version of git is the textconv cache, and it only contains
blobs. Which, AFAIK, cannot be subject to rewriting. So we could put it
off until another such cache comes along.

-Peff