This is a resend of the original patch by Scott Chacon combined with the suggested patch by Johan Herland with a summary of the discussion so far in the hope to restart discussion about including this change. The original thread can be found at [1]. The history so far: The Patch 1/2 was originally submitted to allow using refs outside of the refs/notes/ namespace as notes refs for the purpose of merging notes. However, that patch actually just relaxes the restriction on notes refs so that a fully-qualified ref will be used as-is in the notes code and affects more than just notes merging. The concern was then raised that this is a "stealth-enabler" patch and that even if notes refs are allowed outside of refs/notes/ then they should still be restricted to a some subset (to be determined) of the the refs/ hierarchy and not just allowed anywhere. But, I feel that the rest of Git does not restrict the user in this way -- if the user really wants to do something that is "not recommended" there is almost always a mechanism and/or option to leave the user in control and allow it despite any recommendation(s) to the contrary. So I am resending this summary with attached patches (both of which are very trivial) to allow using any ref for notes as long as it's fully qualified (i.e. starts with "refs/"). Patch 1/2 does that and patch 2/2 fixes the test that breaks because of it. In the hope of restarting discussion towards enabling use of refs outside of refs/notes/ with the notes machinery I conclude by including Peff's final reply to the original thread which I think contains the most compelling aregument for inclusion: On Dec 4, 2014, at 02:26, Jeff King wrote: > On Sat, Nov 22, 2014 at 10:04:57AM -0800, Kyle J. McKay wrote: > >> On Sep 19, 2014, at 11:22, Junio C Hamano wrote: >> >>> By "stealth enabler" I mean the removal of refs/notes/ restriction >>> that was originally done as a safety measure to avoid mistakes of >>> storing notes outside. The refs/remote-notes/ future direction >>> declares that it is no longer a mistake to store notes outside >>> refs/notes/, but that does not necessarily have to mean that >>> anywhere under refs/ is fine. It may make more sense to be explicit >>> with the code touched here to allow traditional refs/notes/ and the >>> new hierarchy only. That way, we will still keep the "avoid >>> mistakes" safety and enable the new layout at the same time. >> >> This is the part where I want to lobby for inclusion of this change. >> I do not believe it is consistent with existing Git practice to >> enforce restrictions like this (you can only display/edit/etc. notes >> under refs/notes/*). > > Yeah, this is the compelling part to me. There is literally no way to > utilize the notes codes for any ref outside of refs/notes currently. > We don't know if refs/remote-notes is the future, or refs/remotes/ > origin/notes, or something else. But we can't even experiment with it in a > meaningful way because the plumbing layer is so restrictive. > > The notes feature has stagnated. Not many people use it because it > requires so much magic to set up and share notes. I think it makes sense to > remove a safety feature that is making it harder to experiment with. If the > worst case is that people start actually _using_ notes and we get > proliferation of places that people are sticking them in the refs hierarchy, > that is vastly preferable IMHO to the current state, in which few people use > them and there is little support for sharing them at all. -Kyle [1] http://thread.gmane.org/gmane.comp.version-control.git/257281 Kyle J. McKay (1): t/t3308-notes-merge.sh: succeed with relaxed notes refs Scott Chacon (1): notes: accept any ref notes.c | 2 +- t/t3308-notes-merge.sh | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) -- 2.1.4 -- 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