I started playing around with sharing git notes and so was happy to see
that git-notes learned about merging since I last tried.

My first try looked as follows (using git 1:1.9.0-1 from Debian):

        $ git fetch $someremote refs/notes/commits
        $ git notes merge FETCH_HEAD
        $ echo $?
        $ git log --oneline refs/notes/commits..FETCH_HEAD | wc -l

Looking at the source I see:

        /* argv[0] holds "FETCH_HEAD" here */
        strbuf_addstr(&remote_ref, argv[0]);

After the call to expand_notes_ref remote_ref contains
"refs/notes/FETCH_HEAD" which isn't what I intended and I'm quite
surprised by. The problem seems to be:

        /* Dereference o->remote_ref into remote_sha1 */
        if (get_sha1(o->remote_ref, remote_sha1)) {
                 * Failed to get remote_sha1. If o->remote_ref looks like an
                 * unborn ref, perform the merge using an empty notes tree.
                if (!check_refname_format(o->remote_ref, 0)) {
                        remote = NULL;
                } else {
                        die("Failed to resolve remote notes ref '%s'",
        } ...

The workaround is obvious (i.e. git update-ref refs/notes/somestring
FETCH_HEAD; git notes merge somestring), but still I think this
behaviour is not optimal. I don't know why one might want to treat a
broken remote side as empty but at least a diagnostic message would be
nice. The same happens if I pass an explicit sha1 instead of

Best regards

Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to