[PATCH v2] notes: handle multiple worktrees

[PATCH v2] notes: handle multiple worktrees

[David Turner]

Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
die_if_shared_symref.  This prevents simultaneous merges to the same
notes branch from different worktrees.

Signed-off-by: David Turner <dturner@twopensource.com>
---

This version addresses Eric Sunshine's critiques of v1.  It breaks out
the symref-checking functionality into die_if_shared_symref, leaving
die_if_checked_out to handle HEAD.

---
 builtin/notes.c                  |  2 ++
 t/t3320-notes-merge-worktrees.sh | 71 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+)
 create mode 100755 t/t3320-notes-merge-worktrees.sh

diff --git a/builtin/notes.c b/builtin/notes.c
index 63f95fc..78a264e 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -19,6 +19,7 @@
 #include "string-list.h"
 #include "notes-merge.h"
 #include "notes-utils.h"
+#include "branch.h"
 
 static const char * const git_notes_usage[] = {
 	N_("git notes [--ref <notes-ref>] [list [<object>]]"),
@@ -829,6 +830,7 @@ static int merge(int argc, const char **argv, const char *prefix)
 		update_ref(msg.buf, "NOTES_MERGE_PARTIAL", result_sha1, NULL,
 			   0, UPDATE_REFS_DIE_ON_ERR);
 		/* Store ref-to-be-updated into .git/NOTES_MERGE_REF */
+		die_if_shared_symref("NOTES_MERGE_REF", default_notes_ref());
 		if (create_symref("NOTES_MERGE_REF", default_notes_ref(), NULL))
 			die("Failed to store link to current notes ref (%s)",
 			    default_notes_ref());
diff --git a/t/t3320-notes-merge-worktrees.sh b/t/t3320-notes-merge-worktrees.sh
new file mode 100755
index 0000000..b102c23
--- /dev/null
+++ b/t/t3320-notes-merge-worktrees.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+#
+# Copyright (c) 2015 Twitter, Inc
+#
+
+test_description='Test merging of notes trees in multiple worktrees'
+
+. ./test-lib.sh
+
+test_expect_success 'setup commit' '
+	test_commit tantrum
+'
+
+commit_tantrum=$(git rev-parse tantrum^{commit})
+
+test_expect_success 'setup notes ref (x)' '
+	git config core.notesRef refs/notes/x &&
+	git notes add -m "x notes on tantrum" tantrum
+'
+
+test_expect_success 'setup local branch (y)' '
+	git update-ref refs/notes/y refs/notes/x &&
+	git config core.notesRef refs/notes/y &&
+	git notes remove tantrum
+'
+
+test_expect_success 'setup remote branch (z)' '
+	git update-ref refs/notes/z refs/notes/x &&
+	git config core.notesRef refs/notes/z &&
+	git notes add -f -m "conflicting notes on tantrum" tantrum
+'
+
+test_expect_success 'modify notes ref ourselves (x)' '
+	git config core.notesRef refs/notes/x &&
+	git notes add -f -m "more conflicting notes on tantrum" tantrum
+'
+
+test_expect_success 'create some new worktrees' '
+	git worktree add -b newbranch worktree master &&
+	git worktree add -b newbranch2 worktree2 master
+'
+
+test_expect_success 'merge z into y fails and sets NOTES_MERGE_REF' '
+	git config core.notesRef refs/notes/y &&
+	test_must_fail git notes merge z &&
+	echo "ref: refs/notes/y" > expect &&
+	test_cmp .git/NOTES_MERGE_REF expect
+'
+
+test_expect_success 'merge z into y while mid-merge in another workdir fails' '
+	(
+		cd worktree &&
+		git config core.notesRef refs/notes/y &&
+		test_must_fail git notes merge z 2>err &&
+		grep "is already checked out" err
+	) &&
+	test_path_is_missing .git/worktrees/worktree/NOTES_MERGE_REF
+'
+
+test_expect_success 'merge z into x while mid-merge on y succeeds' '
+	(
+		cd worktree2 &&
+		git config core.notesRef refs/notes/x &&
+		test_must_fail git notes merge z 2>&1 >out &&
+		grep -v "is already checked out" out
+	) &&
+	echo "ref: refs/notes/x" > expect &&
+	test_cmp .git/worktrees/worktree2/NOTES_MERGE_REF expect
+'
+
+test_done
-- 
2.0.4.315.gad8727a-twtrsrc

Re: [PATCH v2] notes: handle multiple worktrees

[Junio C Hamano]

David Turner <dturner@twopensource.com> writes:

> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
> die_if_shared_symref.  This prevents simultaneous merges to the same
> notes branch from different worktrees.
>
> Signed-off-by: David Turner <dturner@twopensource.com>
> ---
>
> This version addresses Eric Sunshine's critiques of v1.  It breaks out
> the symref-checking functionality into die_if_shared_symref, leaving
> die_if_checked_out to handle HEAD.

>
> ---
>  builtin/notes.c                  |  2 ++
>  t/t3320-notes-merge-worktrees.sh | 71 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 73 insertions(+)
>  create mode 100755 t/t3320-notes-merge-worktrees.sh

Hmm, is this the whole thing?

Or is a prerequisite patch to add that "symref check" infrastructure
missing on the receiving end?

This is a tangent, but there is a bigger spanner in "bisect".  It
uses refs/bisect/* to keep track of the current bisection state, but
that state is tied to a particular worktree, and it should not be
shared across other worktrees.

We need to reserve a part of refs/* hierarchy (e.g. refs/private/*)
for per worktree private stuff and handle them just like we do
per-worktree pseudorefs, or something like that.

Re: [PATCH v2] notes: handle multiple worktrees

[David Turner]

On Fri, 2015-07-31 at 11:46 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
> > die_if_shared_symref.  This prevents simultaneous merges to the same
> > notes branch from different worktrees.
> >
> > Signed-off-by: David Turner <dturner@twopensource.com>
> > ---
> >
> > This version addresses Eric Sunshine's critiques of v1.  It breaks out
> > the symref-checking functionality into die_if_shared_symref, leaving
> > die_if_checked_out to handle HEAD.
> 
> >
> > ---
> >  builtin/notes.c                  |  2 ++
> >  t/t3320-notes-merge-worktrees.sh | 71 ++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 73 insertions(+)
> >  create mode 100755 t/t3320-notes-merge-worktrees.sh
> 
> Hmm, is this the whole thing?
> 
> Or is a prerequisite patch to add that "symref check" infrastructure
> missing on the receiving end?

Oops, resent with first patch included -- I forgot I had split it.

> This is a tangent, but there is a bigger spanner in "bisect".  It
> uses refs/bisect/* to keep track of the current bisection state, but
> that state is tied to a particular worktree, and it should not be
> shared across other worktrees.

Good point.  

> We need to reserve a part of refs/* hierarchy (e.g. refs/private/*)
> for per worktree private stuff and handle them just like we do
> per-worktree pseudorefs, or something like that.

In the pseudorefs series, is_per_worktree_ref is a separate function
precisely so that we can make this sort of change.  To bikeshed a bit, I
propose worktree_refs/*, since:

(a) "private" can have many meanings, and
(b) common_list in path.c doesn't do exceptions ("refs/ except
refs/worktree/").  We could of course do a manual exception, but that's
not pretty.

I further propose to add some patches (to go on top of the pseudorefs
series):

(a) include worktree-refs/ in per_worktree_refs and include
worktree-refs/ in per_worktree_refs in common_list, and
(b) include changes to bisect which switches it over to use
worktree_refs/*.  To make this change compatible with bisections started
with old git versions, we should just unconditionally rename refs/bisect
to worktree-refs/bisect, and, in the event of EISDIR (meaning that both
refs/bisect and worktree-refs/bisect exist), die with a message
explaining the situation.

Re: [PATCH v2] notes: handle multiple worktrees

[Junio C Hamano]

David Turner <dturner@twopensource.com> writes:

> I further propose to add some patches (to go on top of the pseudorefs
> series):
>
> (a) include worktree-refs/ in per_worktree_refs and include
> worktree-refs/ in per_worktree_refs in common_list, and

Do you mean .git/worktree-refs/, just next to .git/refs?  Then I
think it makes sense.

> (b) include changes to bisect which switches it over to use
> worktree_refs/*.  To make this change compatible with bisections started
> with old git versions,...

I personally am not sure if it is worth the effort to cater to those
who start bisection, stop and then upgrade their git version and
expect to continue.