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 -- 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