On Tue, Nov 02, 2010 at 07:11:45AM -0700, Shawn O. Pearce wrote: > I didn't want to use refs/notes/bad-commits because its not really an > annotation you would be looking at with git log. But we do want to > have a log of who banned particular SHA-1s from entering the > repository, and being able to push that branch from a workstation to > the server is a convenient way to edit that list of banned SHA-1s. FWIW, I use refs/notes/cache/textconv/* to store textconv caches, and there is no problem. Unless somebody specifically configures GIT_NOTES_REF or notes.displayRef to see them, log should never look at them. So I think you are being overly cautious. That being said: > I think the docs are correct, and the code is buggy. If the user > asked us to edit refs/meta/bad-commits, we should. If the user asked > us to edit refs/heads/my-branch... well, they asked us to edit it. > :-) I agree. This part of git is unlike most other parts, which tend to DWYM with a partial ref (by prepending refs/heads, refs/tags, etc), but still accept a full ref if the user really feels like organizing their refs differently. > A better safety measure might be to sniff the ref's contents and see > what it is. If the top level directory has a number of non-note like > entries, we should abort editing the branch. Its not common for users > to name their directories "02" and "fe". Agreed. -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