{"thread":{"id":"35920","subject":"$(git notes merge FETCH_HEAD) doesn't work","startedAt":"2014-02-20T15:30:45Z","lastAt":"2014-02-20T15:30:45Z","messageCount":1,"participants":["Uwe Kleine-König"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"235097","messageId":"20140220153045.GI6988@pengutronix.de","threadId":"35920","inReplyTo":null,"subject":"$(git notes merge FETCH_HEAD) doesn't work","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2014-02-20T15:30:45Z","receivedAt":"2014-02-20T15:30:45Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nI started playing around with sharing git notes and so was happy to see\nthat git-notes learned about merging since I last tried.\n\nMy first try looked as follows (using git 1:1.9.0-1 from Debian):\n\n\t$ git fetch $someremote refs/notes/commits\n\t...\n\t$ git notes merge FETCH_HEAD\n\t$ echo $?\n\t0\n\t$ git log --oneline refs/notes/commits..FETCH_HEAD | wc -l\n\t2\n\nLooking at the source I see:\n\n\t/* argv[0] holds \"FETCH_HEAD\" here */\n\tstrbuf_addstr(&remote_ref, argv[0]);\n\texpand_notes_ref(&remote_ref);\n\nAfter the call to expand_notes_ref remote_ref contains\n\"refs/notes/FETCH_HEAD\" which isn't what I intended and I'm quite\nsurprised by. The problem seems to be:\n\n\t/* Dereference o->remote_ref into remote_sha1 */\n\tif (get_sha1(o->remote_ref, remote_sha1)) {\n\t\t/*\n\t\t * Failed to get remote_sha1. If o->remote_ref looks like an\n\t\t * unborn ref, perform the merge using an empty notes tree.\n\t\t */\n\t\tif (!check_refname_format(o->remote_ref, 0)) {\n\t\t\thashclr(remote_sha1);\n\t\t\tremote = NULL;\n\t\t} else {\n\t\t\tdie(\"Failed to resolve remote notes ref '%s'\",\n\t\t\t    o->remote_ref);\n\t\t}\n\t} ...\n\nThe workaround is obvious (i.e. git update-ref refs/notes/somestring\nFETCH_HEAD; git notes merge somestring), but still I think this\nbehaviour is not optimal. I don't know why one might want to treat a\nbroken remote side as empty but at least a diagnostic message would be\nnice. The same happens if I pass an explicit sha1 instead of\n\"FETCH_HEAD\".\n\nBest regards\nUwe\n\n-- \nPengutronix e.K.                           | Uwe Kleine-König            |\nIndustrial Linux Solutions                 | http://www.pengutronix.de/  |\n"}]}