{"thread":{"id":"37593","subject":"[PATCH] notes: accept any ref for merge","startedAt":"2014-09-19T07:39:45Z","lastAt":"2014-12-04T10:26:58Z","messageCount":9,"participants":["Scott Chacon","Jeff King","Johan Herland","Junio C Hamano","Kyle J. McKay"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"249653","messageId":"1411112385-33479-1-git-send-email-schacon@gmail.com","threadId":"37593","inReplyTo":null,"subject":"[PATCH] notes: accept any ref for merge","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2014-09-19T07:39:45Z","receivedAt":"2014-09-19T07:39:45Z","isPatch":true,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Currently if you try to merge notes, the notes code ensures that the\nreference is under the 'refs/notes' namespace. In order to do any sort\nof collaborative workflow, this doesn't work well as you can't easily\nhave local notes refs seperate from remote notes refs.\n\nThis patch changes the expand_notes_ref function to check for simply a\nleading refs/ instead of refs/notes to check if we're being passed an\nexpanded notes reference. This would allow us to set up\nrefs/remotes-notes or otherwise keep mergeable notes references outside\nof what would be contained in the notes push refspec.\n\nSigned-off-by: Scott Chacon \n---\n notes.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/notes.c b/notes.c\nindex 5fe691d..78d58af 100644\n--- a/notes.c\n+++ b/notes.c\n@@ -1293,7 +1293,7 @@ int copy_note(struct notes_tree *t,\n \n void expand_notes_ref(struct strbuf *sb)\n {\n-\tif (starts_with(sb->buf, \"refs/notes/\"))\n+\tif (starts_with(sb->buf, \"refs/\"))\n \t\treturn; /* we're happy */\n \telse if (starts_with(sb->buf, \"notes/\"))\n \t\tstrbuf_insert(sb, 0, \"refs/\", 5);\n-- \n2.0.0\n"},{"id":"249655","messageId":"20140919093910.GA15891@peff.net","threadId":"37593","inReplyTo":"1411112385-33479-1-git-send-email-schacon@gmail.com","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-09-19T09:39:11Z","receivedAt":"2014-09-19T09:39:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:\n\n> Currently if you try to merge notes, the notes code ensures that the\n> reference is under the 'refs/notes' namespace. In order to do any sort\n> of collaborative workflow, this doesn't work well as you can't easily\n> have local notes refs seperate from remote notes refs.\n> \n> This patch changes the expand_notes_ref function to check for simply a\n> leading refs/ instead of refs/notes to check if we're being passed an\n> expanded notes reference. This would allow us to set up\n> refs/remotes-notes or otherwise keep mergeable notes references outside\n> of what would be contained in the notes push refspec.\n\nI think this change affects not just \"git notes merge\", but all of the\nnotes lookups (including just \"git notes show\"). However, I'd argue\nthat's a good thing, as it allows more flexibility in note storage. The\ndownside is that if you have a notes ref like\n\"refs/notes/refs/heads/master\", you can no longer refer to it as\n\"refs/heads/master\" (you have to use the fully qualified name to get the\nnote). But:\n\n 1. This makes the notes resolution a lot more like regular ref\n resolution (i.e., we now allow fully qualified refs, and you can\n store remote notes outside of refs/notes if you want to).\n\n 2. There are already a bunch of names that have the same problem. You\n cannot refer to \"refs/notes/notes/foo\" as \"notes/foo\", nor\n \"refs/notes/refs/notes/foo\" as \"refs/notes/foo\". Yes, these are\n silly names, so is the example above.\n\nSo it's backwards incompatible with the current behavior, but I think in\na good way.\n\n> ---\n> notes.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n\nI think you need to adjust t3308 (and you should probably add a new test\nexercising your case; this is exactly the sort of thing that it's easy\nto accidentally regress later).\n\n-Peff\n"},{"id":"249659","messageId":"CALKQrgc4nZdaXM-Ooh1pP4x4nZRLexJzLyaBmrgn+qVaQGCg+g@mail.gmail.com","threadId":"37593","inReplyTo":"20140919093910.GA15891@peff.net","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-09-19T14:01:38Z","receivedAt":"2014-09-19T14:01:38Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Fri, Sep 19, 2014 at 11:39 AM, Jeff King wrote:\n> On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:\n>> Currently if you try to merge notes, the notes code ensures that the\n>> reference is under the 'refs/notes' namespace. In order to do any sort\n>> of collaborative workflow, this doesn't work well as you can't easily\n>> have local notes refs seperate from remote notes refs.\n>>\n>> This patch changes the expand_notes_ref function to check for simply a\n>> leading refs/ instead of refs/notes to check if we're being passed an\n>> expanded notes reference. This would allow us to set up\n>> refs/remotes-notes or otherwise keep mergeable notes references outside\n>> of what would be contained in the notes push refspec.\n>\n> I think this change affects not just \"git notes merge\", but all of the\n> notes lookups (including just \"git notes show\"). However, I'd argue\n> that's a good thing, as it allows more flexibility in note storage. The\n> downside is that if you have a notes ref like\n> \"refs/notes/refs/heads/master\", you can no longer refer to it as\n> \"refs/heads/master\" (you have to use the fully qualified name to get the\n> note). But:\n>\n> 1. This makes the notes resolution a lot more like regular ref\n> resolution (i.e., we now allow fully qualified refs, and you can\n> store remote notes outside of refs/notes if you want to).\n>\n> 2. There are already a bunch of names that have the same problem. You\n> cannot refer to \"refs/notes/notes/foo\" as \"notes/foo\", nor\n> \"refs/notes/refs/notes/foo\" as \"refs/notes/foo\". Yes, these are\n> silly names, so is the example above.\n>\n> So it's backwards incompatible with the current behavior, but I think in\n> a good way.\n\nFWIW, I agree with this analysis.\n\n>> ---\n>> notes.c | 2 +-\n>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> I think you need to adjust t3308 (and you should probably add a new test\n> exercising your case; this is exactly the sort of thing that it's easy\n> to accidentally regress later).\n\nAgree here as well.\n\nAFAICS, the only diff you'll need to make the test suite pass is this:\n\ndiff --git a/t/t3308-notes-merge.sh b/t/t3308-notes-merge.sh\nindex 24d82b4..f0feb64 100755\n--- a/t/t3308-notes-merge.sh\n+++ b/t/t3308-notes-merge.sh\n@@ -90,7 +90,6 @@ test_expect_success 'fail to merge various non-note-trees' '\n test_must_fail git notes merge refs/notes/ &&\n test_must_fail git notes merge refs/notes/dir &&\n test_must_fail git notes merge refs/notes/dir/ &&\n- test_must_fail git notes merge refs/heads/master &&\n test_must_fail git notes merge x: &&\n test_must_fail git notes merge x:foo &&\n test_must_fail git notes merge foo^{bar\n\nAdditionally, I suggest adding another test demonstrating your use\ncase as well. Something like setting up a small scenario for notes\ncollaboration, and walking through the various steps:\n\n - Creating a couple of repos where notes are added/edited\n - Setting up config to allow pushing and/or fetching notes\n - Performing the push/fetch\n - Merging with the corresponding local notes ref\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"249671","messageId":"xmqq4mw3o6xj.fsf@gitster.dls.corp.google.com","threadId":"37593","inReplyTo":"20140919093910.GA15891@peff.net","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-19T17:29:12Z","receivedAt":"2014-09-19T17:29:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think this change affects not just \"git notes merge\", but all of the\n> notes lookups (including just \"git notes show\"). However, I'd argue\n> that's a good thing, as it allows more flexibility in note storage. The\n> downside is that if you have a notes ref like\n> \"refs/notes/refs/heads/master\", you can no longer refer to it as\n> \"refs/heads/master\" (you have to use the fully qualified name to get the\n> note). But:\n>\n> 1. This makes the notes resolution a lot more like regular ref\n> resolution (i.e., we now allow fully qualified refs, and you can\n> store remote notes outside of refs/notes if you want to).\n>\n> 2. There are already a bunch of names that have the same problem. You\n> cannot refer to \"refs/notes/notes/foo\" as \"notes/foo\", nor\n> \"refs/notes/refs/notes/foo\" as \"refs/notes/foo\". Yes, these are\n> silly names, so is the example above.\n>\n> So it's backwards incompatible with the current behavior, but I think in\n> a good way.\n\nYup, I agree with the analysis.\n\n>> ---\n>> notes.c | 2 +-\n>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> I think you need to adjust t3308 (and you should probably add a new test\n> exercising your case; this is exactly the sort of thing that it's easy\n> to accidentally regress later).\n>\n> -Peff\n"},{"id":"249676","messageId":"xmqqoaubmpvh.fsf@gitster.dls.corp.google.com","threadId":"37593","inReplyTo":"CALKQrgc4nZdaXM-Ooh1pP4x4nZRLexJzLyaBmrgn+qVaQGCg+g@mail.gmail.com","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-19T18:22:58Z","receivedAt":"2014-09-19T18:22:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> On Fri, Sep 19, 2014 at 11:39 AM, Jeff King wrote:\n>> On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:\n>>> Currently if you try to merge notes, the notes code ensures that the\n>>> reference is under the 'refs/notes' namespace. In order to do any sort\n>>> of collaborative workflow, this doesn't work well as you can't easily\n>>> have local notes refs seperate from remote notes refs.\n>>>\n>>> This patch changes the expand_notes_ref function to check for simply a\n>>> leading refs/ instead of refs/notes to check if we're being passed an\n>>> expanded notes reference. This would allow us to set up\n>>> refs/remotes-notes or otherwise keep mergeable notes references outside\n>>> of what would be contained in the notes push refspec.\n>>\n>> I think this change affects not just \"git notes merge\", but all of the\n>> notes lookups (including just \"git notes show\")....\n> ...\n> Additionally, I suggest adding another test demonstrating your use\n> case as well. Something like setting up a small scenario for notes\n> collaboration, and walking through the various steps:\n>\n> - Creating a couple of repos where notes are added/edited\n> - Setting up config to allow pushing and/or fetching notes\n> - Performing the push/fetch\n> - Merging with the corresponding local notes ref\n\nIs it our future direction to set up refs/remote-notes//\nnamespace? If so, let's not do it piecemeail in an unorganized\nguerrilla fashion by starting with a stealth enabler with an\nassociated test. We risk not following through and leave the\nresulting user experience more puzzling if we go that way.\n\nBy \"stealth enabler\" I mean the removal of refs/notes/ restriction\nthat was originally done as a safety measure to avoid mistakes of\nstoring notes outside. The refs/remote-notes/ future direction\ndeclares that it is no longer a mistake to store notes outside\nrefs/notes/, but that does not necessarily have to mean that\nanywhere under refs/ is fine. It may make more sense to be explicit\nwith the code touched here to allow traditional refs/notes/ and the\nnew hierarchy only. That way, we will still keep the \"avoid\nmistakes\" safety and enable the new layout at the same time.\n\nThe most important first step for that to happen is to make sure we\nare on the same page on that future direction. I personally think\nrefs/remote-notes/ that runs parallel to the remote tracking\nbranch hierarchy refs/remotes/ is a reasonable way to do\nthis, but my words are no way final.\n\nAssuming that this is we all agree to go in that direction, let's\nmake a list of things to be done to codify it, and do them. For a\nstarter, I think these are needed, perhaps?\n\n - This patch (or an enhancement to keep some safety)\n\n - Documentation updates to \"git notes\"\n\n - Documentation updates to Documentation/gitrepository-layout.txt\n\n - Update to \"git clone\" and \"git remote add\" to add a fetch refspec\n refs/notes:refs/remote-refs//*\n\n - New tests you suggest\n"},{"id":"249682","messageId":"CALKQrgd3PzwgxuhrTpNCi-zuOj3PYviknpKgfPYVWP6bNS8AqQ@mail.gmail.com","threadId":"37593","inReplyTo":"xmqqoaubmpvh.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-09-20T00:01:58Z","receivedAt":"2014-09-20T00:01:58Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Fri, Sep 19, 2014 at 8:22 PM, Junio C Hamano wrote:\n> Johan Herland writes:\n>> On Fri, Sep 19, 2014 at 11:39 AM, Jeff King wrote:\n>>> On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:\n>>>> Currently if you try to merge notes, the notes code ensures that the\n>>>> reference is under the 'refs/notes' namespace. In order to do any sort\n>>>> of collaborative workflow, this doesn't work well as you can't easily\n>>>> have local notes refs seperate from remote notes refs.\n>>>>\n>>>> This patch changes the expand_notes_ref function to check for simply a\n>>>> leading refs/ instead of refs/notes to check if we're being passed an\n>>>> expanded notes reference. This would allow us to set up\n>>>> refs/remotes-notes or otherwise keep mergeable notes references outside\n>>>> of what would be contained in the notes push refspec.\n>>>\n>>> I think this change affects not just \"git notes merge\", but all of the\n>>> notes lookups (including just \"git notes show\")....\n>> ...\n>> Additionally, I suggest adding another test demonstrating your use\n>> case as well. Something like setting up a small scenario for notes\n>> collaboration, and walking through the various steps:\n>>\n>> - Creating a couple of repos where notes are added/edited\n>> - Setting up config to allow pushing and/or fetching notes\n>> - Performing the push/fetch\n>> - Merging with the corresponding local notes ref\n>\n> Is it our future direction to set up refs/remote-notes//\n> namespace? If so, let's not do it piecemeail in an unorganized\n> guerrilla fashion by starting with a stealth enabler with an\n> associated test. We risk not following through and leave the\n> resulting user experience more puzzling if we go that way.\n>\n> By \"stealth enabler\" I mean the removal of refs/notes/ restriction\n> that was originally done as a safety measure to avoid mistakes of\n> storing notes outside. The refs/remote-notes/ future direction\n> declares that it is no longer a mistake to store notes outside\n> refs/notes/, but that does not necessarily have to mean that\n> anywhere under refs/ is fine. It may make more sense to be explicit\n> with the code touched here to allow traditional refs/notes/ and the\n> new hierarchy only. That way, we will still keep the \"avoid\n> mistakes\" safety and enable the new layout at the same time.\n>\n> The most important first step for that to happen is to make sure we\n> are on the same page on that future direction. I personally think\n> refs/remote-notes/ that runs parallel to the remote tracking\n> branch hierarchy refs/remotes/ is a reasonable way to do\n> this, but my words are no way final.\n\nThis has been discussed several times in the past, and - as I have\nargued before - I believe Git would benefit from a more thorough\nrevamp of the ref namespace, one that would allow a straightforward\nnaming of _any_ kind of remote-tracking ref (heads, tags, notes,\nwhatever). The scheme I have proposed would map refs//\nfrom a remote repo to a remote-tracking\nrefs/remotes/// in the local repo.\n\nHaving said that, I have clearly failed to find the time and\nmotivation to follow through on this topic, and although there was\nsome support for the idea, nobody else has stepped up to tackle it.\nUnfortunately, that has left \"git notes\" in a sorry state when it\ncomes to sharing and collaboration. This has to stop. Fixing notes\nsharing is much more important than whatever lofty ideas I might\nhave about how things should \"ideally\" be organized.\n\nTherefore, you can count me in support of organizing remote-tracking\nnotes refs under refs/remote-notes//. In case of a more\nthorough redesign of the ref namespace at some point in the future,\nwe will have to deal with a lot of \"legacy\" anyway, and adding\nrefs/remote-notes/ will not considerably increase that\nburden.\n\n> Assuming that this is we all agree to go in that direction, let's\n> make a list of things to be done to codify it, and do them. For a\n> starter, I think these are needed, perhaps?\n>\n> - This patch (or an enhancement to keep some safety)\n>\n> - Documentation updates to \"git notes\"\n>\n> - Documentation updates to Documentation/gitrepository-layout.txt\n>\n> - Update to \"git clone\" and \"git remote add\" to add a fetch refspec\n> refs/notes:refs/remote-refs//*\n>\n> - New tests you suggest\n\nSounds good to me. At least that would get us to the point where a\nsimple \"git fetch\" will also fetch notes updates, and you can then\nchoose to \"git notes merge\" them into your corresponding local notes\nrefs.\n\nIn addition to that we might want to consider streamlining things\nfurther by having a single command (like \"git pull\") that performs\nboth fetching and merging. A complication here is that - unlike the\nbranch realm where HEAD points to our \"current\" branch - there is\nnot really a concept of a \"current\" notes ref, which could specify\n_which_ remote-notes ref to merge and/or the parameters of that\nmerge. However, (as usual) I'm getting ahead of myself here. The\npoints you list above go more than halfway to making notes sharing\nstraightforward, and are in any case necessary prerequisites for\nwhatever might follow.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"249740","messageId":"xmqqsijjlfsy.fsf@gitster.dls.corp.google.com","threadId":"37593","inReplyTo":"CALKQrgd3PzwgxuhrTpNCi-zuOj3PYviknpKgfPYVWP6bNS8AqQ@mail.gmail.com","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-22T17:34:53Z","receivedAt":"2014-09-22T17:34:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n>> Assuming that this is we all agree to go in that direction, let's\n>> make a list of things to be done to codify it, and do them. For a\n>> starter, I think these are needed, perhaps?\n>> ...\n> Sounds good to me. At least that would ...\n> ...\n> In addition to that we might want to consider ...\n\nYes, I specifically meant my list as \"a starter\", not wanting to\nmake an exhaustive list myself.\n"},{"id":"252378","messageId":"6b21dd7a53200ab413c67bb4667e8bc@74d39fa044aa309eaea14b9f57fe79c","threadId":"37593","inReplyTo":"xmqqoaubmpvh.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-11-22T18:04:57Z","receivedAt":"2014-11-22T18:04:57Z","isPatch":true,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"I see this patch has not been picked up.\n\nI would like to lobby for inclusion of this patch.\n\nOn Sep 19, 2014, at 11:22, Junio C Hamano wrote:\n\n> Johan Herland writes:\n>\n>> On Fri, Sep 19, 2014 at 11:39 AM, Jeff King wrote:\n>>> On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:\n>>>> This patch changes the expand_notes_ref function to check for \n>>>> simply a\n>>>> leading refs/ instead of refs/notes to check if we're being \n>>>> passed an\n>>>> expanded notes reference.\n>>>\n>>> I think this change affects not just \"git notes merge\", but all of \n>>> the\n>>> notes lookups (including just \"git notes show\")....\n>> ...\n>\n> Is it our future direction to set up refs/remote-notes//\n> namespace?\n\nWhen cloning (without --mirror) Git now sets up a fetch spec like:\n\n +refs/heads/*:refs/remotes/origin/*\n\nIt's unfortunate that it does not preserve the notion of \"heads\" and \ninstead set it up like this:\n\n +refs/heads/*:refs/remotes/origin/heads/*\n\nIn which case it would make more sense to then simply clone notes like \nso:\n\n +refs/notes/*:refs/remotes/origin/notes/*\n\nThat would also clear the way to always fetching all remote tags into \nrefs/remotes//tags/* by default as well even if the local refs/ \ntags/* do not end up being updated.\n\nIt seems clumsy to me to use a new remotes-notes ref namespace. What \nhappens if Git grows the ability to store some kind of (bug) tracking \nticket in refs/tickets in the future? Does Git then use refs/remote- \ntickets/ to store the remote refs rather than simply refs/ \nremotes//tickets?\n\nThere are a number of applications that create refs outside of refs/ \nheads/* and refs/tags/*. GitHub uses refs/pull/*, should Git have a \nrefs/remote-pull//* namespace and for Gerrit refs/remote- \nchanges//* and also refs/remote-cache-automerge//* \n(for refs/cache-automerge/*)?\n\n> If so, let's not do it piecemeail in an unorganized\n> guerrilla fashion by starting with a stealth enabler\n>\n> By \"stealth enabler\" I mean the removal of refs/notes/ restriction\n> that was originally done as a safety measure to avoid mistakes of\n> storing notes outside. The refs/remote-notes/ future direction\n> declares that it is no longer a mistake to store notes outside\n> refs/notes/, but that does not necessarily have to mean that\n> anywhere under refs/ is fine. It may make more sense to be explicit\n> with the code touched here to allow traditional refs/notes/ and the\n> new hierarchy only. That way, we will still keep the \"avoid\n> mistakes\" safety and enable the new layout at the same time.\n\nThis is the part where I want to lobby for inclusion of this change. \nI do not believe it is consistent with existing Git practice to \nenforce restrictions like this (you can only display/edit/etc. notes \nunder refs/notes/*).\n\nAlready that's not true if you use an ugly symbolic-ref workaround, \nbut that requires polluting your ref namespace.\n\nWith all the other Git \"restrictions\" they are almost always strong \nguidance, not brutally enforced.\n\nTake, for example, the \"restriction\" that HEAD should be either \ndetached or a symbolic ref to refs/heads/.\n\nIt's not absolutely enforced. If you really want to, you can use git \nsymbolic-ref and set HEAD to somewhere else (even under refs/taga) -- \nand it mostly works -- `git branch` gets upset but you can commit new \nchanges, view the log, etc.\n\nHow about the \"guidance\" that pushing does not update tags even if the \nchange would be a fast-forward? Again, not enforced, use the -f \noption or add an explicit refspec to the appropriate remote config.\n\nWhat about the restriction that `git config --get user.name` cannot \nend in \".\"? (It gets magically stripped off.) That's a toughie, but \nif you really, really, really want to you can always `git cat-file \ncommit HEAD > temp`, add the trailing dot and then git update-ref HEAD \n$(git hash-object -t commit -w temp)`. Not recommended but possible.\n\nSo anyway, my point is that arbitrarily forcefully restricting the \noperation of the various notes commands to refs/notes/* does not seem \nconsistent with the way everything else works.\n\n> The most important first step for that to happen is to make sure we\n> are on the same page on that future direction. I personally think\n> refs/remote-notes/ that runs parallel to the remote tracking\n> branch hierarchy refs/remotes/ is a reasonable way to do\n> this, but my words are no way final.\n\nI'd prefer refs/remotes//notes for the reasons stated above. \nHaving a refs/remote-notes//* hierarchy opens the door to a \nproliferation of refs/remote-//* items in the refs \nnamespace in the future.\n\nSo in the vein of providing guidance to the user but, in the end, \nallowing the user to remain in control, I have gussied up Johan's \nsuggested fix for the failing notes test into the following patch.\n\n--Kyle\n\n-- 8< --\nSubject: [PATCH] t/t3308-notes-merge.sh: succeed with relaxed notes refs\n\nWith the recent change to allow notes refs to be located in\nthe refs hierarchy in locations other than refs/notes/ the\n'git notes merge refs/heads/master' test started succeeding.\n\nPreviously refs/heads/master would have been expanded to\na non-existing, ref refs/notes/refs/heads/master, and the\nmerge would have failed (as expected).\n\nNow, however, since refs/heads/master exists and the new,\nmore relaxed notes refs rules leave it unchanged, the merge\nsucceeds. This has a follow-on effect which makes the\nnext two tests fail as well.\n\nThe refs/heads/master ref could just be replaced with\nanother ref name that does not exist such as refs/heads/xmaster,\nbut there are already several tests using non-existant refs\nso instead just remove the refs/heads/master line.\n\nSuggested-by: Johan Herland \nSigned-off-by: Kyle J. McKay \n---\n t/t3308-notes-merge.sh | 1 -\n 1 file changed, 1 deletion(-)\n\ndiff --git a/t/t3308-notes-merge.sh b/t/t3308-notes-merge.sh\nindex 24d82b49..f0feb64b 100755\n--- a/t/t3308-notes-merge.sh\n+++ b/t/t3308-notes-merge.sh\n@@ -90,7 +90,6 @@ test_expect_success 'fail to merge various non-note-trees' '\n \ttest_must_fail git notes merge refs/notes/ &&\n \ttest_must_fail git notes merge refs/notes/dir &&\n \ttest_must_fail git notes merge refs/notes/dir/ &&\n-\ttest_must_fail git notes merge refs/heads/master &&\n \ttest_must_fail git notes merge x: &&\n \ttest_must_fail git notes merge x:foo &&\n \ttest_must_fail git notes merge foo^{bar\n"},{"id":"253048","messageId":"20141204102657.GA27739@peff.net","threadId":"37593","inReplyTo":"6b21dd7a53200ab413c67bb4667e8bc@74d39fa044aa309eaea14b9f57fe79c","subject":"Re: [PATCH] notes: accept any ref for merge","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-04T10:26:58Z","receivedAt":"2014-12-04T10:26:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 22, 2014 at 10:04:57AM -0800, Kyle J. McKay wrote:\n\n> > By \"stealth enabler\" I mean the removal of refs/notes/ restriction\n> > that was originally done as a safety measure to avoid mistakes of\n> > storing notes outside. The refs/remote-notes/ future direction\n> > declares that it is no longer a mistake to store notes outside\n> > refs/notes/, but that does not necessarily have to mean that\n> > anywhere under refs/ is fine. It may make more sense to be explicit\n> > with the code touched here to allow traditional refs/notes/ and the\n> > new hierarchy only. That way, we will still keep the \"avoid\n> > mistakes\" safety and enable the new layout at the same time.\n> \n> This is the part where I want to lobby for inclusion of this change. \n> I do not believe it is consistent with existing Git practice to \n> enforce restrictions like this (you can only display/edit/etc. notes \n> under refs/notes/*).\n\nYeah, this is the compelling part to me. There is literally no way to\nutilize the notes codes for any ref outside of refs/notes currently. We\ndon't know if refs/remote-notes is the future, or refs/remotes/origin/notes,\nor something else. But we can't even experiment with it in a meaningful way\nbecause the plumbing layer is so restrictive.\n\nThe notes feature has stagnated. Not many people use it because it requires\nso much magic to set up and share notes. I think it makes sense to remove a\nsafety feature that is making it harder to experiment with. If the worst\ncase is that people start actually _using_ notes and we get proliferation of\nplaces that people are sticking them in the refs hierarchy, that is vastly\npreferable IMHO to the current state, in which few people use them and there\nis little support for sharing them at all.\n\nThe original patch discussion sort of fizzled, and your response here\nlargely slipped through the cracks. I am not sure everyone even\nremembers the exact patch under discussion. Maybe a better way to\nre-kickstart the discussion is to repost the patch along with a synopsis\nof the previous discussion and your arguments about moving it forward.\n\n-Peff\n"}]}