Hello,
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 $?
0
$ git log --oneline refs/notes/commits..FETCH_HEAD | wc -l
2
Looking at the source I see:
/* argv[0] holds "FETCH_HEAD" here */
strbuf_addstr(&remote_ref, argv[0]);
expand_notes_ref(&remote_ref);
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)) {
hashclr(remote_sha1);
remote = NULL;
} else {
die("Failed to resolve remote notes ref '%s'",
o->remote_ref);
}
} ...
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
"FETCH_HEAD".
Best regards
Uwe
--
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
