[PATCH v4 0/4] add notes strategy configuration options

[PATCH v4 0/4] add notes strategy configuration options

[Jacob Keller]

From: Jacob Keller <jacob.keller@gmail.com>

This series of patches implements notes.merge and notes.<ref>.merge
options for configuring notes merge strategy such that user may avoid
typing "-s". It is (probably) most useful if the user wishes to always
enforce cat_sort_uniq strategy.

This series now uses git_config_get_string_const() instead of trying to
change the git_default_config setup. In addition, the 4th patch is much
smaller and avoids a lot of heavy cruft due to this change.

I tried to re-work everything I noticed from the email list, but please
shout if I did not manage to recall your suggestion.

The new version should be much simpler to understand.

Changes since v3:
* don't use hash table, instead just call "git_config_get_string_const"
* notes.<ref>.merge must always be fully qualified, (since notes doesn't
  enforce the refs to be always in refs/notes, so we shouldn't either)
* fixed documentation to reduce confusion over which strategies are
  accepted for options
* ensure tests cover "notes.<ref>.merge" overrides "notes.merge"

I also tried to make sure the reviewers were all Cc'ed on every patch
not just the first one this time.

Jacob Keller (4):
  notes: document cat_sort_uniq rewriteMode
  notes: add tests for --commit/--abort/--strategy exclusivity
  notes: add notes.merge option to select default strategy
  notes: teach git-notes about notes.<ref>.merge option

 Documentation/config.txt              | 17 +++++++--
 Documentation/git-notes.txt           | 23 ++++++++++--
 builtin/notes.c                       | 49 ++++++++++++++++---------
 notes-merge.h                         | 16 +++++----
 t/t3309-notes-merge-auto-resolve.sh   | 68 +++++++++++++++++++++++++++++++++++
 t/t3310-notes-merge-manual-resolve.sh | 12 +++++++
 6 files changed, 157 insertions(+), 28 deletions(-)

-- 
2.5.0.482.gfcd5645

[PATCH v4 1/4] notes: document cat_sort_uniq rewriteMode

[Jacob Keller]

From: Jacob Keller <jacob.keller@gmail.com>

Teach documentation about the cat_sort_uniq rewriteMode that got added
at the same time as the equivalent merge strategy.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
---
 Documentation/config.txt    | 4 ++--
 Documentation/git-notes.txt | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index da74ad0d0aca..b3df1b16491c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1933,8 +1933,8 @@ notes.rewriteMode::
 	When copying notes during a rewrite (see the
 	"notes.rewrite.<command>" option), determines what to do if
 	the target commit already has a note.  Must be one of
-	`overwrite`, `concatenate`, or `ignore`.  Defaults to
-	`concatenate`.
+	`overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
+	Defaults to `concatenate`.
 +
 This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
 environment variable.
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 851518d531b5..674682b34b83 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -331,7 +331,8 @@ environment variable.
 notes.rewriteMode::
 	When copying notes during a rewrite, what to do if the target
 	commit already has a note.  Must be one of `overwrite`,
-	`concatenate`, and `ignore`.  Defaults to `concatenate`.
+	`concatenate`, `cat_sort_uniq`, or `ignore`.  Defaults to
+	`concatenate`.
 +
 This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
 environment variable.
-- 
2.5.0.482.gfcd5645

[PATCH v4 2/4] notes: add tests for --commit/--abort/--strategy exclusivity

[Jacob Keller]

From: Jacob Keller <jacob.keller@gmail.com>

Add new tests to ensure that --commit, --abort, and --strategy are
mutually exclusive.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
---
 t/t3310-notes-merge-manual-resolve.sh | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/t/t3310-notes-merge-manual-resolve.sh b/t/t3310-notes-merge-manual-resolve.sh
index 195bb97f859d..d5572121da69 100755
--- a/t/t3310-notes-merge-manual-resolve.sh
+++ b/t/t3310-notes-merge-manual-resolve.sh
@@ -314,6 +314,18 @@ y and z notes on 1st commit
 
 EOF
 
+test_expect_success 'do not allow mixing --commit and --abort' '
+	test_must_fail git notes merge --commit --abort
+'
+
+test_expect_success 'do not allow mixing --commit and --strategy' '
+	test_must_fail git notes merge --commit --strategy theirs
+'
+
+test_expect_success 'do not allow mixing --abort and --strategy' '
+	test_must_fail git notes merge --abort --strategy theirs
+'
+
 test_expect_success 'finalize conflicting merge (z => m)' '
 	# Resolve conflicts and finalize merge
 	cat >.git/NOTES_MERGE_WORKTREE/$commit_sha1 <<EOF &&
-- 
2.5.0.482.gfcd5645

[PATCH v4 3/4] notes: add notes.merge option to select default strategy

[Jacob Keller]

From: Jacob Keller <jacob.keller@gmail.com>

Teach git-notes about "notes.merge" to select a general strategy for all
notes merges. This enables a user to always get expected merge strategy
such as "cat_sort_uniq" without having to pass the "-s" option manually.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
---
 Documentation/config.txt            |  7 ++++++
 Documentation/git-notes.txt         | 14 +++++++++++-
 builtin/notes.c                     | 44 +++++++++++++++++++++++--------------
 notes-merge.h                       | 16 ++++++++------
 t/t3309-notes-merge-auto-resolve.sh | 29 ++++++++++++++++++++++++
 5 files changed, 86 insertions(+), 24 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index b3df1b16491c..488c2e8eec1b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1905,6 +1905,13 @@ mergetool.writeToTemp::
 mergetool.prompt::
 	Prompt before each invocation of the merge resolution program.
 
+notes.merge::
+	Which merge strategy to choose by default when resolving notes
+	conflicts. Must be one of `manual`, `ours`, `theirs`, `union`,
+	or `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE
+	STRATEGIES" section of linkgit:git-notes[1] for more information
+	on each strategy.
+
 notes.displayRef::
 	The (fully qualified) refname from which to show notes when
 	showing commit messages.  The value of this variable can be set
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 674682b34b83..9c4f8536182f 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -101,7 +101,7 @@ merge::
 	any) into the current notes ref (called "local").
 +
 If conflicts arise and a strategy for automatically resolving
-conflicting notes (see the -s/--strategy option) is not given,
+conflicting notes (see the "NOTES MERGE STRATEGIES" section) is not given,
 the "manual" resolver is used. This resolver checks out the
 conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`),
 and instructs the user to manually resolve the conflicts there.
@@ -183,6 +183,7 @@ OPTIONS
 	When merging notes, resolve notes conflicts using the given
 	strategy. The following strategies are recognized: "manual"
 	(default), "ours", "theirs", "union" and "cat_sort_uniq".
+	This option overrides the "notes.merge" configuration setting.
 	See the "NOTES MERGE STRATEGIES" section below for more
 	information on each notes merge strategy.
 
@@ -247,6 +248,9 @@ When done, the user can either finalize the merge with
 'git notes merge --commit', or abort the merge with
 'git notes merge --abort'.
 
+Users may select an automated merge strategy from among the following using
+either -s/--strategy option or configuring notes.merge accordingly:
+
 "ours" automatically resolves conflicting notes in favor of the local
 version (i.e. the current notes ref).
 
@@ -310,6 +314,14 @@ core.notesRef::
 	This setting can be overridden through the environment and
 	command line.
 
+notes.merge::
+	Which merge strategy to choose by default when resolving notes
+	conflicts. Must be one of `manual`, `ours`, `theirs`, `union`,
+	or `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE
+	STRATEGIES" section above for more information on each strategy.
++
+This setting can be overridden by passing the `--strategy` option.
+
 notes.displayRef::
 	Which ref (or refs, if a glob or specified more than once), in
 	addition to the default set by `core.notesRef` or
diff --git a/builtin/notes.c b/builtin/notes.c
index 63f95fc55439..3c705f5e26ff 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -737,6 +737,24 @@ static int merge_commit(struct notes_merge_options *o)
 	return ret;
 }
 
+static int parse_notes_strategy(const char *arg, enum notes_merge_strategy *strategy)
+{
+	if (!strcmp(arg, "manual"))
+		*strategy = NOTES_MERGE_RESOLVE_MANUAL;
+	else if (!strcmp(arg, "ours"))
+		*strategy = NOTES_MERGE_RESOLVE_OURS;
+	else if (!strcmp(arg, "theirs"))
+		*strategy = NOTES_MERGE_RESOLVE_THEIRS;
+	else if (!strcmp(arg, "union"))
+		*strategy = NOTES_MERGE_RESOLVE_UNION;
+	else if (!strcmp(arg, "cat_sort_uniq"))
+		*strategy = NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ;
+	else
+		return -1;
+
+	return 0;
+}
+
 static int merge(int argc, const char **argv, const char *prefix)
 {
 	struct strbuf remote_ref = STRBUF_INIT, msg = STRBUF_INIT;
@@ -745,7 +763,7 @@ static int merge(int argc, const char **argv, const char *prefix)
 	struct notes_merge_options o;
 	int do_merge = 0, do_commit = 0, do_abort = 0;
 	int verbosity = 0, result;
-	const char *strategy = NULL;
+	const char *strategy = NULL, *configured_strategy = NULL;
 	struct option options[] = {
 		OPT_GROUP(N_("General options")),
 		OPT__VERBOSITY(&verbosity),
@@ -795,21 +813,15 @@ static int merge(int argc, const char **argv, const char *prefix)
 	expand_notes_ref(&remote_ref);
 	o.remote_ref = remote_ref.buf;
 
-	if (strategy) {
-		if (!strcmp(strategy, "manual"))
-			o.strategy = NOTES_MERGE_RESOLVE_MANUAL;
-		else if (!strcmp(strategy, "ours"))
-			o.strategy = NOTES_MERGE_RESOLVE_OURS;
-		else if (!strcmp(strategy, "theirs"))
-			o.strategy = NOTES_MERGE_RESOLVE_THEIRS;
-		else if (!strcmp(strategy, "union"))
-			o.strategy = NOTES_MERGE_RESOLVE_UNION;
-		else if (!strcmp(strategy, "cat_sort_uniq"))
-			o.strategy = NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ;
-		else {
-			error("Unknown -s/--strategy: %s", strategy);
-			usage_with_options(git_notes_merge_usage, options);
-		}
+	git_config_get_string_const("notes.merge", &configured_strategy);
+
+	if (configured_strategy &&
+	    parse_notes_strategy(configured_strategy, &o.strategy))
+		die("Unknown notes merge strategy: %s", configured_strategy);
+
+	if (strategy && parse_notes_strategy(strategy, &o.strategy)) {
+		error("Unknown -s/--strategy: %s", strategy);
+		usage_with_options(git_notes_merge_usage, options);
 	}
 
 	t = init_notes_check("merge");
diff --git a/notes-merge.h b/notes-merge.h
index 1d01f6aacf54..bda8c0c8d348 100644
--- a/notes-merge.h
+++ b/notes-merge.h
@@ -8,18 +8,20 @@ enum notes_merge_verbosity {
 	NOTES_MERGE_VERBOSITY_MAX = 5
 };
 
+enum notes_merge_strategy {
+	NOTES_MERGE_RESOLVE_MANUAL = 0,
+	NOTES_MERGE_RESOLVE_OURS,
+	NOTES_MERGE_RESOLVE_THEIRS,
+	NOTES_MERGE_RESOLVE_UNION,
+	NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ
+};
+
 struct notes_merge_options {
 	const char *local_ref;
 	const char *remote_ref;
 	struct strbuf commit_msg;
 	int verbosity;
-	enum {
-		NOTES_MERGE_RESOLVE_MANUAL = 0,
-		NOTES_MERGE_RESOLVE_OURS,
-		NOTES_MERGE_RESOLVE_THEIRS,
-		NOTES_MERGE_RESOLVE_UNION,
-		NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ
-	} strategy;
+	enum notes_merge_strategy strategy;
 	unsigned has_worktree:1;
 };
 
diff --git a/t/t3309-notes-merge-auto-resolve.sh b/t/t3309-notes-merge-auto-resolve.sh
index 461fd84755d7..a773b01b73db 100755
--- a/t/t3309-notes-merge-auto-resolve.sh
+++ b/t/t3309-notes-merge-auto-resolve.sh
@@ -298,6 +298,13 @@ test_expect_success 'merge z into y with invalid strategy => Fail/No changes' '
 	verify_notes y y
 '
 
+test_expect_success 'merge z into y with invalid configuration option => Fail/No changes' '
+	git config core.notesRef refs/notes/y &&
+	test_must_fail git -c notes.merge="foo" notes merge z &&
+	# Verify no changes (y)
+	verify_notes y y
+'
+
 cat <<EOF | sort >expect_notes_ours
 68b8630d25516028bed862719855b3d6768d7833 $commit_sha15
 5de7ea7ad4f47e7ff91989fb82234634730f75df $commit_sha14
@@ -365,6 +372,17 @@ test_expect_success 'reset to pre-merge state (y)' '
 	verify_notes y y
 '
 
+test_expect_success 'merge z into y with "ours" configuration option => Non-conflicting 3-way merge' '
+	git -c notes.merge="ours" notes merge z &&
+	verify_notes y ours
+'
+
+test_expect_success 'reset to pre-merge state (y)' '
+	git update-ref refs/notes/y refs/notes/y^1 &&
+	# Verify pre-merge state
+	verify_notes y y
+'
+
 cat <<EOF | sort >expect_notes_theirs
 9b4b2c61f0615412da3c10f98ff85b57c04ec765 $commit_sha15
 5de7ea7ad4f47e7ff91989fb82234634730f75df $commit_sha14
@@ -432,6 +450,17 @@ test_expect_success 'reset to pre-merge state (y)' '
 	verify_notes y y
 '
 
+test_expect_success 'merge z into y with "theirs" strategy overriding configuration option "ours" => Non-conflicting 3-way merge' '
+	git -c notes.merge="ours" notes merge --strategy=theirs z &&
+	verify_notes y theirs
+'
+
+test_expect_success 'reset to pre-merge state (y)' '
+	git update-ref refs/notes/y refs/notes/y^1 &&
+	# Verify pre-merge state
+	verify_notes y y
+'
+
 cat <<EOF | sort >expect_notes_union
 7c4e546efd0fe939f876beb262ece02797880b54 $commit_sha15
 5de7ea7ad4f47e7ff91989fb82234634730f75df $commit_sha14
-- 
2.5.0.482.gfcd5645

[PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

From: Jacob Keller <jacob.keller@gmail.com>

Add new option "notes.<ref>.merge" option which specifies the merge
strategy for merging into a given notes ref. This option enables
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 <ref> 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. Also,
notes.<ref>.merge overrides the general behavior as it is more specific.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
---
 Documentation/config.txt            |  6 ++++++
 Documentation/git-notes.txt         |  6 ++++++
 builtin/notes.c                     |  7 +++++--
 t/t3309-notes-merge-auto-resolve.sh | 39 +++++++++++++++++++++++++++++++++++++
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 488c2e8eec1b..2c283ebc309e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1912,6 +1912,12 @@ notes.merge::
 	STRATEGIES" section of linkgit:git-notes[1] for more information
 	on each strategy.
 
+notes.<localref>.merge::
+	Which merge strategy to choose if the local ref for a notes merge
+	matches <localref>, overriding "notes.merge". <localref> just be a
+	fully qualified refname. See "NOTES MERGE STRATEGIES" section in
+	linkgit:git-notes[1] for more information on the available strategies.
+
 notes.displayRef::
 	The (fully qualified) refname from which to show notes when
 	showing commit messages.  The value of this variable can be set
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 9c4f8536182f..68fae8d22555 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -322,6 +322,12 @@ notes.merge::
 +
 This setting can be overridden by passing the `--strategy` option.
 
+notes.<localref>.merge::
+	Which strategy to choose when merging into <localref>. The set of
+	allowed values is the same as "notes.merge". <localref> must be a fully
+	qualified refname. See "NOTES MERGE STRATEGIES" section above for more
+	information about each strategy.
+
 notes.displayRef::
 	Which ref (or refs, if a glob or specified more than once), in
 	addition to the default set by `core.notesRef` or
diff --git a/builtin/notes.c b/builtin/notes.c
index 3c705f5e26ff..2f2d7e87ef47 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -757,7 +757,7 @@ static int parse_notes_strategy(const char *arg, enum notes_merge_strategy *stra
 
 static int merge(int argc, const char **argv, const char *prefix)
 {
-	struct strbuf remote_ref = STRBUF_INIT, msg = STRBUF_INIT;
+	struct strbuf remote_ref = STRBUF_INIT, msg = STRBUF_INIT, merge_key = STRBUF_INIT;
 	unsigned char result_sha1[20];
 	struct notes_tree *t;
 	struct notes_merge_options o;
@@ -813,7 +813,10 @@ static int merge(int argc, const char **argv, const char *prefix)
 	expand_notes_ref(&remote_ref);
 	o.remote_ref = remote_ref.buf;
 
-	git_config_get_string_const("notes.merge", &configured_strategy);
+	strbuf_addf(&merge_key, "notes.%s.merge", o.local_ref);
+
+	if (git_config_get_string_const(merge_key.buf, &configured_strategy))
+		git_config_get_string_const("notes.merge", &configured_strategy);
 
 	if (configured_strategy &&
 	    parse_notes_strategy(configured_strategy, &o.strategy))
diff --git a/t/t3309-notes-merge-auto-resolve.sh b/t/t3309-notes-merge-auto-resolve.sh
index a773b01b73db..b0bbc0a6bac2 100755
--- a/t/t3309-notes-merge-auto-resolve.sh
+++ b/t/t3309-notes-merge-auto-resolve.sh
@@ -383,6 +383,17 @@ test_expect_success 'reset to pre-merge state (y)' '
 	verify_notes y y
 '
 
+test_expect_success 'merge z into y with "ours" per-ref configuration option => Non-conflicting 3-way merge' '
+	git -c notes.refs/notes/y.merge="ours" notes merge z &&
+	verify_notes y ours
+'
+
+test_expect_success 'reset to pre-merge state (y)' '
+	git update-ref refs/notes/y refs/notes/y^1 &&
+	# Verify pre-merge state
+	verify_notes y y
+'
+
 cat <<EOF | sort >expect_notes_theirs
 9b4b2c61f0615412da3c10f98ff85b57c04ec765 $commit_sha15
 5de7ea7ad4f47e7ff91989fb82234634730f75df $commit_sha14
@@ -534,6 +545,34 @@ test_expect_success 'reset to pre-merge state (y)' '
 	verify_notes y y
 '
 
+test_expect_success 'merge z into y with "union" strategy overriding per-ref configuration => Non-conflicting 3-way merge' '
+	git -c notes.refs/notes/y.merge="theirs" notes merge --strategy=union z &&
+	verify_notes y union
+'
+
+test_expect_success 'reset to pre-merge state (y)' '
+	git update-ref refs/notes/y refs/notes/y^1 &&
+	# Verify pre-merge state
+	verify_notes y y
+'
+
+test_expect_success 'merge z into y with "union" per-ref overriding general configuration => Non-conflicting 3-way merge' '
+	git -c notes.refs/notes/y.merge="union" -c notes.merge="theirs" notes merge z &&
+	verify_notes y union
+'
+
+test_expect_success 'reset to pre-merge state (y)' '
+	git update-ref refs/notes/y refs/notes/y^1 &&
+	# Verify pre-merge state
+	verify_notes y y
+'
+
+test_expect_success 'merge z into y with "manual" per-ref only checks specific ref configuration => Conflicting 3-way merge' '
+	test_must_fail git -c notes.refs/notes/z.merge="union" notes merge z &&
+	git notes merge --abort &&
+	verify_notes y y
+'
+
 cat <<EOF | sort >expect_notes_union2
 d682107b8bf7a7aea1e537a8d5cb6a12b60135f1 $commit_sha15
 5de7ea7ad4f47e7ff91989fb82234634730f75df $commit_sha14
-- 
2.5.0.482.gfcd5645

Re: [PATCH v4 3/4] notes: add notes.merge option to select default strategy

[Johan Herland]

On Tue, Aug 11, 2015 at 10:57 PM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Teach git-notes about "notes.merge" to select a general strategy for all
> notes merges. This enables a user to always get expected merge strategy
> such as "cat_sort_uniq" without having to pass the "-s" option manually.
>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
> ---
>  Documentation/config.txt            |  7 ++++++
>  Documentation/git-notes.txt         | 14 +++++++++++-
>  builtin/notes.c                     | 44 +++++++++++++++++++++++--------------
>  notes-merge.h                       | 16 ++++++++------
>  t/t3309-notes-merge-auto-resolve.sh | 29 ++++++++++++++++++++++++
>  5 files changed, 86 insertions(+), 24 deletions(-)
>
[...]
> diff --git a/builtin/notes.c b/builtin/notes.c
> index 63f95fc55439..3c705f5e26ff 100644
> --- a/builtin/notes.c
> +++ b/builtin/notes.c
> @@ -737,6 +737,24 @@ static int merge_commit(struct notes_merge_options *o)
>         return ret;
>  }
>
> +static int parse_notes_strategy(const char *arg, enum notes_merge_strategy *strategy)
> +{
> +       if (!strcmp(arg, "manual"))
> +               *strategy = NOTES_MERGE_RESOLVE_MANUAL;
> +       else if (!strcmp(arg, "ours"))
> +               *strategy = NOTES_MERGE_RESOLVE_OURS;
> +       else if (!strcmp(arg, "theirs"))
> +               *strategy = NOTES_MERGE_RESOLVE_THEIRS;
> +       else if (!strcmp(arg, "union"))
> +               *strategy = NOTES_MERGE_RESOLVE_UNION;
> +       else if (!strcmp(arg, "cat_sort_uniq"))
> +               *strategy = NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ;
> +       else
> +               return -1;
> +
> +       return 0;
> +}
> +
>  static int merge(int argc, const char **argv, const char *prefix)
>  {
>         struct strbuf remote_ref = STRBUF_INIT, msg = STRBUF_INIT;
> @@ -745,7 +763,7 @@ static int merge(int argc, const char **argv, const char *prefix)
>         struct notes_merge_options o;
>         int do_merge = 0, do_commit = 0, do_abort = 0;
>         int verbosity = 0, result;
> -       const char *strategy = NULL;
> +       const char *strategy = NULL, *configured_strategy = NULL;
>         struct option options[] = {
>                 OPT_GROUP(N_("General options")),
>                 OPT__VERBOSITY(&verbosity),
> @@ -795,21 +813,15 @@ static int merge(int argc, const char **argv, const char *prefix)
>         expand_notes_ref(&remote_ref);
>         o.remote_ref = remote_ref.buf;
>
> -       if (strategy) {
> -               if (!strcmp(strategy, "manual"))
> -                       o.strategy = NOTES_MERGE_RESOLVE_MANUAL;
> -               else if (!strcmp(strategy, "ours"))
> -                       o.strategy = NOTES_MERGE_RESOLVE_OURS;
> -               else if (!strcmp(strategy, "theirs"))
> -                       o.strategy = NOTES_MERGE_RESOLVE_THEIRS;
> -               else if (!strcmp(strategy, "union"))
> -                       o.strategy = NOTES_MERGE_RESOLVE_UNION;
> -               else if (!strcmp(strategy, "cat_sort_uniq"))
> -                       o.strategy = NOTES_MERGE_RESOLVE_CAT_SORT_UNIQ;
> -               else {
> -                       error("Unknown -s/--strategy: %s", strategy);
> -                       usage_with_options(git_notes_merge_usage, options);
> -               }
> +       git_config_get_string_const("notes.merge", &configured_strategy);
> +
> +       if (configured_strategy &&
> +           parse_notes_strategy(configured_strategy, &o.strategy))
> +               die("Unknown notes merge strategy: %s", configured_strategy);
> +
> +       if (strategy && parse_notes_strategy(strategy, &o.strategy)) {
> +               error("Unknown -s/--strategy: %s", strategy);
> +               usage_with_options(git_notes_merge_usage, options);
>         }

Do you need to look at the notes.merge config variable at all if
-s/--strategy is given?
I'd expect the above to rather look something like:

if (strategy) {
        if (parse_notes_strategy(strategy, &o.strategy)) {
                error("Unknown -s/--strategy: %s", strategy);
                usage_with_options(git_notes_merge_usage, options);
        }
} else if (configured_strategy) {
        if (parse_notes_strategy(configured_strategy, &o.strategy))
                die("Unknown notes merge strategy: %s", configured_strategy);
} /* else o.strategy = NOTES_MERGE_RESOLVE_MANUAL; */


Otherwise, this patch looks good to me.

...Johan


-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Eric Sunshine]

On Tue, Aug 11, 2015 at 4:57 PM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> Add new option "notes.<ref>.merge" option which specifies the merge
> strategy for merging into a given notes ref. This option enables
> 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 <ref> 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. Also,
> notes.<ref>.merge overrides the general behavior as it is more specific.
>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 488c2e8eec1b..2c283ebc309e 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1912,6 +1912,12 @@ notes.merge::
>         STRATEGIES" section of linkgit:git-notes[1] for more information
>         on each strategy.
>
> +notes.<localref>.merge::
> +       Which merge strategy to choose if the local ref for a notes merge
> +       matches <localref>, overriding "notes.merge". <localref> just be a

s/just/must/

> +       fully qualified refname. See "NOTES MERGE STRATEGIES" section in
> +       linkgit:git-notes[1] for more information on the available strategies.
> +

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Johan Herland]

On Tue, Aug 11, 2015 at 10:57 PM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Add new option "notes.<ref>.merge" option which specifies the merge
> strategy for merging into a given notes ref. This option enables
> 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 <ref> 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. Also,
> notes.<ref>.merge overrides the general behavior as it is more specific.

Thanks for working on this, and I apologize for not properly reviewing
this part of the series before now. More comments below.

>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
> ---
>  Documentation/config.txt            |  6 ++++++
>  Documentation/git-notes.txt         |  6 ++++++
>  builtin/notes.c                     |  7 +++++--
>  t/t3309-notes-merge-auto-resolve.sh | 39 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 488c2e8eec1b..2c283ebc309e 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1912,6 +1912,12 @@ notes.merge::
>         STRATEGIES" section of linkgit:git-notes[1] for more information
>         on each strategy.
>
> +notes.<localref>.merge::
> +       Which merge strategy to choose if the local ref for a notes merge
> +       matches <localref>, overriding "notes.merge". <localref> just be a

s/just/must/

> +       fully qualified refname. See "NOTES MERGE STRATEGIES" section in
> +       linkgit:git-notes[1] for more information on the available strategies.

I sort of get the reason for "fully qualified refname", but I think

  notes.refs/notes/commits.merge

looks much uglier than

  notes.commits.merge

Especially since we have the opposite precedence for branch.<name>.*,
e.g. we already have

  branch.master.merge

and not

  branch.refs/heads/master.merge

I know that we don't yet have a "proper" place to put remote notes refs,
but the <ref> in notes.<ref>.merge _must_ be a "local" notes ref (you even
use the <localref> notation in the documentation below). Thus, I believe
we can presume that the local notes ref must live under refs/notes/*,
and hence drop the "refs/notes/" prefix from the config key (just like
branch.<name>.* can presume that <name> lives under refs/heads/*).

...

Which brings me to another small gripe about the naming here:
branch.<name>.merge names the remote ref (at branch.<name>.remote)
that we will pull from, but notes.<ref>.merge has a very different
meaning.

If we - in the future - were to provide a similar config mechanism for a
hypothetical "git notes pull" command, then it would be natural to model
its config similarly: notes.<name>.remote and notes.<name>.merge
specifies whence we fetch, and what we (notes-)merge, respectively.

Except that this patch in its current form will occupy the .merge config
key...

Can you rename to notes.<name>.mergestrategy instead? Or even better,
take inspiration from branch.<name>.mergeoptions, and provide
notes.<name>.mergeoptions instead, which you can then set like:

  git config notes.foo.mergeoptions "--strategy=cat_sort_uniq"

Even though 'git notes merge' don't yet accept any other options that
should be configurable, I think it's worth emulating the mechanisms
that alread exist for branches. It gives is some amount of future-
proofing as well.


...Johan


-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH v4 1/4] notes: document cat_sort_uniq rewriteMode

[Johan Herland]

On Tue, Aug 11, 2015 at 10:57 PM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Teach documentation about the cat_sort_uniq rewriteMode that got added
> at the same time as the equivalent merge strategy.
>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>

Reviewed-by: Johan Herland <johan@herland.net>

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH v4 2/4] notes: add tests for --commit/--abort/--strategy exclusivity

[Johan Herland]

On Tue, Aug 11, 2015 at 10:57 PM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> Add new tests to ensure that --commit, --abort, and --strategy are
> mutually exclusive.
>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>

Reviewed-by: Johan Herland <johan@herland.net>

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Junio C Hamano]

Johan Herland <johan@herland.net> writes:

> I know that we don't yet have a "proper" place to put remote notes refs,
> but the <ref> in notes.<ref>.merge _must_ be a "local" notes ref (you even
> use the <localref> notation in the documentation below). Thus, I believe
> we can presume that the local notes ref must live under refs/notes/*,
> and hence drop the "refs/notes/" prefix from the config key (just like
> branch.<name>.* can presume that <name> lives under refs/heads/*).

I am OK going in that direction, as long as we promise that "notes
merge" will forever refuse to work on --notes=$ref where $ref does
not begin with refs/notes/.

> Except that this patch in its current form will occupy the .merge config
> key...
>
> Can you rename to notes.<name>.mergestrategy instead?

This is an excellent suggestion.

> Or even better, take inspiration from branch.<name>.mergeoptions,

Please don't.

That is one of the design mistakes that was copied from another
design mistake (remotes.*.tagopt).  I'd want to see us not to repeat
these design mistakes.

These configuration variables were made to take free-form text value
that is split according to shell rules, primarily because it was
expedient to implement.  Read its value into a $variable and put it
at the end of the command line to let the shell split it.  "tagopt"
was done a bit more carefully in that it made to react only with a
fixed string "--no-tags", so it was hard to abuse, but "mergeoptions"
allowed you to override something that you wouldn't want to (e.g. it
even allowed you to feed '--message=foo').

Once you start from such a broken design, it would be hard to later
make it saner, even if you wanted to.  You have to retroactively
forbid something that "worked" (with some definition of "working"),
or you have to split, parse and then reject something that does not
make sense yourself, reimplementing dequote/split rule used in the
shell---which is especially problematic when you no longer write in
shell scripts.

So a single string value that names one of the supported strategy
stored in notes.<name>.mergestrategy is an excellent choice.  An
arbitrary string in notes.<name>.mergeoptions is to be avoided.

Thanks.

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

On Tue, Aug 11, 2015 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
>
>> I know that we don't yet have a "proper" place to put remote notes refs,
>> but the <ref> in notes.<ref>.merge _must_ be a "local" notes ref (you even
>> use the <localref> notation in the documentation below). Thus, I believe
>> we can presume that the local notes ref must live under refs/notes/*,
>> and hence drop the "refs/notes/" prefix from the config key (just like
>> branch.<name>.* can presume that <name> lives under refs/heads/*).
>
> I am OK going in that direction, as long as we promise that "notes
> merge" will forever refuse to work on --notes=$ref where $ref does
> not begin with refs/notes/.
>

It appears that notes merge already allows operating on refs not in "refs/notes"

the way you select what you are merging into is via either --ref or
the environment variable.I chose to use the full refs/notes/* format
as it was the only one that also supported all layouts.

So, should we enforce that default_notes_ref always requires refs
inside refs/notes? that doesn't seem a bad idea here.

If we only disallow it for merge I think that would be very confusing.

Regards,
Jake

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> On Tue, Aug 11, 2015 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Johan Herland <johan@herland.net> writes:
>>
>>> I know that we don't yet have a "proper" place to put remote notes refs,
>>> but the <ref> in notes.<ref>.merge _must_ be a "local" notes ref (you even
>>> use the <localref> notation in the documentation below). Thus, I believe
>>> we can presume that the local notes ref must live under refs/notes/*,
>>> and hence drop the "refs/notes/" prefix from the config key (just like
>>> branch.<name>.* can presume that <name> lives under refs/heads/*).
>>
>> I am OK going in that direction, as long as we promise that "notes
>> merge" will forever refuse to work on --notes=$ref where $ref does
>> not begin with refs/notes/.
>
> It appears that notes merge already allows operating on refs not in "refs/notes"

If that is the case, then the only sane choice left to us is to
accept only fully qualified refname, e.g. refs/notes/commit, in
notes.<ref>.mergestrategy, without shortening, I would think.

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

On Wed, Aug 12, 2015 at 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> On Tue, Aug 11, 2015 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Johan Herland <johan@herland.net> writes:
>>>
>>>> I know that we don't yet have a "proper" place to put remote notes refs,
>>>> but the <ref> in notes.<ref>.merge _must_ be a "local" notes ref (you even
>>>> use the <localref> notation in the documentation below). Thus, I believe
>>>> we can presume that the local notes ref must live under refs/notes/*,
>>>> and hence drop the "refs/notes/" prefix from the config key (just like
>>>> branch.<name>.* can presume that <name> lives under refs/heads/*).
>>>
>>> I am OK going in that direction, as long as we promise that "notes
>>> merge" will forever refuse to work on --notes=$ref where $ref does
>>> not begin with refs/notes/.
>>
>> It appears that notes merge already allows operating on refs not in "refs/notes"
>
> If that is the case, then the only sane choice left to us is to
> accept only fully qualified refname, e.g. refs/notes/commit, in
> notes.<ref>.mergestrategy, without shortening, I would think.

Oh interesting. I did a test. If you provide a fully qualified ref not
inside refs/notes, then it assumes you meant refs/notes/refs/foo/y
rather than refs/foo/y

I need to do some more digging on this to determine the exact thing going on...

Regards,
Jake

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

On Wed, Aug 12, 2015 at 12:16 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> Oh interesting. I did a test. If you provide a fully qualified ref not
> inside refs/notes, then it assumes you meant refs/notes/refs/foo/y
> rather than refs/foo/y
>
> I need to do some more digging on this to determine the exact thing going on...
>
> Regards,
> Jake

I did some more digging. If you pass a notes ref to "--refs" option,
that requires all notes to be bound to refs/notes/* and does not allow
passing of arbitrary refs. However, you can set the environment
variable GIT_NOTES_REF or core.notesRef to a fully qualified
reference.

That seems very arbitrary that --ref works by expanding notes and the
environment variable and configuration option do not... [1]

I think this inconsistency is very weird, because *most* people will
not use refs/notes/* etc. This makes it so that --refs forces you to
use refs/notes/* or it will prefix it for you... ie: you can use
notes/x, refs/notes/x, x, but if you use refs/tags/x it will DWIM into
refs/notes/refs/tags/x

I think this is very confusing that --refs doesn't behave the same as
other sections... either we should enforce this on all refs or we
should fix the DWIM-ery to be consistent.

that is, we should fix DWIM-ery to be:

(1) if it starts with refs/* leave it alone

(2) if it starts with notes/*, prefix it with refs/

(3) otherwise prefix it with refs/notes/

But that way, refs/some-other-notes/ will work fine instead of
becoming something else.

We should also fix reads of environment variable etc such taht we
enforce these values always are fully qualified and begin with refs.
Otherwise, use of --refs and the environment variable don't allow the
same formats.

Regards,
Jake

[1] 8ef313e1ec3b ("builtin/notes.c: Split notes ref DWIMmery into a
separate function")

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Johan Herland]

On Wed, Aug 12, 2015 at 4:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
>> I know that we don't yet have a "proper" place to put remote notes refs,
>> but the <ref> in notes.<ref>.merge _must_ be a "local" notes ref (you even
>> use the <localref> notation in the documentation below). Thus, I believe
>> we can presume that the local notes ref must live under refs/notes/*,
>> and hence drop the "refs/notes/" prefix from the config key (just like
>> branch.<name>.* can presume that <name> lives under refs/heads/*).
>
> I am OK going in that direction, as long as we promise that "notes
> merge" will forever refuse to work on --notes=$ref where $ref does
> not begin with refs/notes/.

If we don't already refuse to merge into a ref outside refs/notes, then
I would consider that a bug to be fixed, and not some corner use case that
we must preserve for all future.

After all, we do already have a test in t3308 named 'fail to merge into
various non-notes refs', where one of the non-notes ref being tested are:

  test_must_fail git -c "core.notesRef=refs/heads/master" notes merge x

>> Except that this patch in its current form will occupy the .merge config
>> key...
>>
>> Can you rename to notes.<name>.mergestrategy instead?
>
> This is an excellent suggestion.
>
>> Or even better, take inspiration from branch.<name>.mergeoptions,
>
> Please don't.
>
> That is one of the design mistakes that was copied from another
> design mistake (remotes.*.tagopt).  I'd want to see us not to repeat
> these design mistakes.
>
> These configuration variables were made to take free-form text value
> that is split according to shell rules, primarily because it was
> expedient to implement.  Read its value into a $variable and put it
> at the end of the command line to let the shell split it.  "tagopt"
> was done a bit more carefully in that it made to react only with a
> fixed string "--no-tags", so it was hard to abuse, but "mergeoptions"
> allowed you to override something that you wouldn't want to (e.g. it
> even allowed you to feed '--message=foo').
>
> Once you start from such a broken design, it would be hard to later
> make it saner, even if you wanted to.  You have to retroactively
> forbid something that "worked" (with some definition of "working"),
> or you have to split, parse and then reject something that does not
> make sense yourself, reimplementing dequote/split rule used in the
> shell---which is especially problematic when you no longer write in
> shell scripts.
>
> So a single string value that names one of the supported strategy
> stored in notes.<name>.mergestrategy is an excellent choice.  An
> arbitrary string in notes.<name>.mergeoptions is to be avoided.

Understood. And agreed.

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

On Wed, Aug 12, 2015 at 2:46 PM, Johan Herland <johan@herland.net> wrote:
> If we don't already refuse to merge into a ref outside refs/notes, then
> I would consider that a bug to be fixed, and not some corner use case that
> we must preserve for all future.
>
> After all, we do already have a test in t3308 named 'fail to merge into
> various non-notes refs', where one of the non-notes ref being tested are:
>
>   test_must_fail git -c "core.notesRef=refs/heads/master" notes merge x
>

This test is checking if the ref pointed at by refs/heads/master *is*
a note. But you could create a ref outside of refs/notes which is a
note but which isn't inside refs/notes

I did just find that we expand remote-ref using expand_notes_ref, and
it does *not* currently let us reference refs outside of refs/notes..
so we can merge IN to a ref not inside refs/notes (using the
environment variable) but we can't merge FROM
refs/tracking/origin/notes/y for example, which means currently all
notes we merge from have to be located into refs/notes/*

There are some weird issues here.

Regards,
Jake

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

On Wed, Aug 12, 2015 at 2:57 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Wed, Aug 12, 2015 at 2:46 PM, Johan Herland <johan@herland.net> wrote:
>> If we don't already refuse to merge into a ref outside refs/notes, then
>> I would consider that a bug to be fixed, and not some corner use case that
>> we must preserve for all future.
>>
>> After all, we do already have a test in t3308 named 'fail to merge into
>> various non-notes refs', where one of the non-notes ref being tested are:
>>
>>   test_must_fail git -c "core.notesRef=refs/heads/master" notes merge x
>>
>
> This test is checking if the ref pointed at by refs/heads/master *is*
> a note. But you could create a ref outside of refs/notes which is a
> note but which isn't inside refs/notes
>
> I did just find that we expand remote-ref using expand_notes_ref, and
> it does *not* currently let us reference refs outside of refs/notes..
> so we can merge IN to a ref not inside refs/notes (using the
> environment variable) but we can't merge FROM
> refs/tracking/origin/notes/y for example, which means currently all
> notes we merge from have to be located into refs/notes/*
>
> There are some weird issues here.
>
> Regards,
> Jake


I spoke to soon. We have an "init_notes_check" function which shows
that it does refuse to merge outside of refs/notes/* It prevents all
notes operations outside of refs/notes

Since this is the case, I would prefer to modify the DWIM to be as I
suggested, and use this DWIM for the notes.

We will need to modify the DWIM so that it doesn't change refs/* even
if this will fail later, as we use expand_notes_ref for the remote_ref
of a merge, and we probably want to allow notes refs to be located
somewhere outside of notes such as refs/tracking/<origin>/notes or
something in the future.

So we can make our config option take only unqualified values.

Thoughts?

Regards,
Jake

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Johan Herland]

On Wed, Aug 12, 2015 at 11:43 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Wed, Aug 12, 2015 at 12:16 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> Oh interesting. I did a test. If you provide a fully qualified ref not
>> inside refs/notes, then it assumes you meant refs/notes/refs/foo/y
>> rather than refs/foo/y
>>
>> I need to do some more digging on this to determine the exact thing going on...
>>
>> Regards,
>> Jake
>
> I did some more digging. If you pass a notes ref to "--refs" option,

You're referring to the --ref option to 'git notes'?

> that requires all notes to be bound to refs/notes/* and does not allow
> passing of arbitrary refs. However, you can set the environment
> variable GIT_NOTES_REF or core.notesRef to a fully qualified
> reference.
>
> That seems very arbitrary that --ref works by expanding notes and the
> environment variable and configuration option do not... [1]

I believe the intention here was to provide the DWIM-ing at the most
end-user-facing interface (leaving the two other interfaces as possible
"loopholes" for e.g. scripts that "known what they're doing" and don't
want the DWIM-ery to get in their way). Looking back at it now, that
approach was probably misguided.

> I think this inconsistency is very weird, because *most* people will
> not use refs/notes/* etc. This makes it so that --refs forces you to
> use refs/notes/* or it will prefix it for you... ie: you can use
> notes/x, refs/notes/x, x, but if you use refs/tags/x it will DWIM into
> refs/notes/refs/tags/x
>
> I think this is very confusing that --refs doesn't behave the same as
> other sections... either we should enforce this on all refs or we
> should fix the DWIM-ery to be consistent.
>
> that is, we should fix DWIM-ery to be:
>
> (1) if it starts with refs/* leave it alone
>
> (2) if it starts with notes/*, prefix it with refs/
>
> (3) otherwise prefix it with refs/notes/
>
> But that way, refs/some-other-notes/ will work fine instead of
> becoming something else.

Yes, that is probably a better way to do the DWIM-ery.

However, we then need to provide an additional layer of safety/checks
that prevent notes operations from manipulating non-notes refs. First:

 - As mentioned elsewhere in the thread, git notes merge should certainly
   refuse to merge into anything not under refs/notes/*.

 - Preferably, all notes _manipulation_ should be limited to only operating
   under refs/notes/* (although I haven't fully thought through all of the
   ramifications of that).

 - Notes _querying_ (as opposed to manipulation) should be allowed both
   within and outside refs/notes/*

I think this should cover the use cases where you fetch notes from a remote
and put them in e.g. refs/remote-notes/* (or refs/remotes/origin/notes/*).
After all, you should not manipulate those notes directly (just as you
don't manipulate your remote-tracking branches directly), but you should
definitely be able to query them, and merge them into a _local_ notes ref
(living under refs/notes/*).

Does that make sense?

> We should also fix reads of environment variable etc such taht we
> enforce these values always are fully qualified and begin with refs.
> Otherwise, use of --refs and the environment variable don't allow the
> same formats.

Agreed.


...Johan

> Regards,
> Jake
>
> [1] 8ef313e1ec3b ("builtin/notes.c: Split notes ref DWIMmery into a
> separate function")
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> I spoke to soon. We have an "init_notes_check" function which shows
> that it does refuse to merge outside of refs/notes/* It prevents all
> notes operations outside of refs/notes

OK.  Then it is OK to limit notes.<ref>.mergestrategy so that <ref>
refers to what comes after refs/notes/, because we will not allow
merging to happen outside the hierarchy.

If you are planning to break that promise, however, <ref> must be
always spelled fully (i.e. with refs/notes/ prefix for those inside
the hierarchy) to avoid ambiguity.  Otherwise it will be hard to
interpret a configuration that does something like this (note that
these could come from multiple places, e.g. $HOME/.gitconfig and
$GIT_DIR/config):

    [notes "commits"]
        mergestrategy = concatenate
    [notes "notes/commits"]
        mergestrategy = cat_sort_uniq
    [notes "refs/notes/commits"]
        mergestrategy = overwrite

The three entries in the above example obviously are all meant to
refer to the same refs/notes/commits notes tree, and the usual "last
one wins" rule should apply.  But with the recent git_config_get_*()
interface, you cannot tell which one among them was given the last,
overriding the previous entries.

Re: [PATCH v4 4/4] notes: teach git-notes about notes.<ref>.merge option

[Jacob Keller]

On Wed, Aug 12, 2015 at 3:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> I spoke to soon. We have an "init_notes_check" function which shows
>> that it does refuse to merge outside of refs/notes/* It prevents all
>> notes operations outside of refs/notes
>
> OK.  Then it is OK to limit notes.<ref>.mergestrategy so that <ref>
> refers to what comes after refs/notes/, because we will not allow
> merging to happen outside the hierarchy.
>
> If you are planning to break that promise, however, <ref> must be
> always spelled fully (i.e. with refs/notes/ prefix for those inside
> the hierarchy) to avoid ambiguity.  Otherwise it will be hard to
> interpret a configuration that does something like this (note that
> these could come from multiple places, e.g. $HOME/.gitconfig and
> $GIT_DIR/config):
>

Agreed. Today, we do not allow any notes operations at all that
function outside of refs/notes/*

I suggest we enforce that all configs for merge strategy must be the
unqualified notation, and not allow the variance of refs/notes/* and
such that DWIM does on the command line.

>     [notes "commits"]
>         mergestrategy = concatenate
>     [notes "notes/commits"]
>         mergestrategy = cat_sort_uniq
>     [notes "refs/notes/commits"]
>         mergestrategy = overwrite
>
> The three entries in the above example obviously are all meant to
> refer to the same refs/notes/commits notes tree, and the usual "last
> one wins" rule should apply.  But with the recent git_config_get_*()
> interface, you cannot tell which one among them was given the last,
> overriding the previous entries.

Ya, I'd like to avoid this if possible.

Regards,
Jake