Merging git notes when there are merge conflicts in them

Question

I followed these instructions in order to merge Git notes.

I cloned a repo, added notes reference to the commit (refs/notes/commits). When i push it, central repo rejects it as it was non-fast forward—because there was already a refs/notes/commits for that commit object. So in order to merge that remote Notes reference to my local Notes reference,

$ git checkout refs/notes/master
$ git fetch refs/notes/commits
$ git merge FETCH_HEAD
Auto-merging 206155715a78c9d91d42cda1de98449d2e0b1d36<br>
CONFLICT (add/add): Merge conflict in 206155715a78c9d91d42cda1de98449d........
Automatic merge failed; fix conflicts and then commit the result.
$ vi 206155715a78c9d91d42cda1de98449d........ [fix the conflict as usual manually]
$ git add 206155715a78c9d91d42cda1de98449d........
$ git commit -m "updated Notes"
[detached HEAD 0afb80f] changed notes
$ git update-ref refs/notes/commits HEAD
$ git checkout master <br>
Previous HEAD position was 0afb80f... changed notes
Switched to branch 'master'
$ git push origin refs/notes/commits
success

The question is, whether is this the best way to do this?

Following git notes man page, I tried the following.

$ git fetch refs/notes/commits
$ git notes merge -v refs/notes/commits
Nothing to Update!

The above steps obviously didn’t work for me. Is there a way to use the git notes merge command and merge the Notes, rather than the "branch method" as shown in the first illustration? For my uses, this straightforward command would be more helpful.

Answer 1

As I already alluded to in a comment, one reason the first approach is not working for you is that you copied the instructions wrong: your second step git fetch refs/notes/commits is missing the name of the remote.

Regarding the second approach with git notes merge, again you have made the same mistake of missing the remote from the git fetch. But even with this fixed I struggled to get it to work until I finally figured out that you have to fetch the notes from the remote into a different ref namespace prior to merging, since if there is a conflict it won't let you overwrite what the local refs/notes/commits points to (although it will happily fast-forward it if there is no conflict).

So this works for me:

git fetch origin refs/notes/commits:refs/notes/origin/commits
git notes merge -v origin/commits

If there are conflicts, it will now tell you to edit .git/NOTES_MERGE_WORKTREE and then commit the result via git notes merge --commit, or abort the merge with git notes merge --abort.

One big disadvantage of using git notes merge over the technique suggested in the URL above is that the merge does not provide any index, so you can't use your normal merging workflow via git mergetool etc. Another is that it doesn't support rebasing. So if you expect complicated conflicts or need to rebase then I'd recommend going with the git checkout refs/notes/commits approach. But in the simple case, git notes merge is probably more convenient because you can perform the merge whilst your working tree is dirty, whereas git checkout refs/notes/commits requires it to be clean.

I'm pretty sure that the git-notes(1) man page could make this all a lot more obvious. Maybe I'll find some time to submit a patch for that. In the mean time however, I've written a new wrapper called git-rnotes which makes it easier to share notes to and from remote repositories.

Answer 2

Note: git 2.6 (Q3/Q4 2015) will make git notes merge a bit more efficient and precise:

See commit 4f655e2, commit d2d68d9, commit 11dd2b2, commit 93efcad, commit 4d03dd1, commit e48ad1b (17 Aug 2015) by Jacob Keller (jacob-keller).
^{(Merged by Junio C Hamano -- gitster -- in commit 5b6211a, 31 Aug 2015)}

notes: teach git notes about notes.<name>.mergeStrategy option

Teach notes about a new "notes.<name>.mergeStrategy" option for configuring the notes merge strategy when merging into refs/notes/<name>.
This option allows for the selection of merge strategy for particular notes refs, rather than all notes ref merges, as user may not want cat_sort_uniq for all refs, but only some.
Note that the <name> is the local reference we are merging into, not the remote ref we merged from. The assumption is that users will mostly want to configure separate local ref merge strategies rather than strategies depending on which remote ref they merge from.

notes.<name>.mergeStrategy overrides the general behavior as it is more specific.