threads / patch / 31447

patch, 2 partsAdd --expand to 'git notes get-ref'

Subject: [PATCH 0/2] Add --expand to 'git notes get-ref'

## tl;dr

11 messages between Sep 5, 2012 and Sep 10, 2012. Diffs are folded; open one to read it.

replies: 10people: 3as markdown or json

W. Trevor King· Sep 5, 2012, 12:48 UTC · lore
From: "W. Trevor King" <wking@tremily.us>
I was recently confused when
  $ git notes merge -v refs/remotes/origin/notes/commits

failed to do (or print) anything. It turns out that note refs must live under 'refs/notes/', so my command line ref was expanding to

  refs/notes/refs/remotes/origin/notes/commits
which wasn't matching anything.

The first of my commits here adds the '--expand' option, so you can see how Git is expanding your ref internally:

  $ GIT_NOTES_REF=commits git notes get-ref --expand
  refs/notes/commits

The second commit makes the expansion less strict about the location of note refs. In his initial mail introducing 'git notes', Johan says that note refs should live under 'refs/notes' [1]. This seems like a good place for local notes, but note refs from remote repos should probably live somewhere else (e.g. 'refs/remote-notes/' or 'refs/remotes/<name>/notes/'. In the initial thread there are a few messages talking about looking up reverse mappings under 'refs/notes/', but this seems to all have been before the 'refs/notes/<namespace>/' stage. If I'm missing a good reason to keep everything under 'refs/notes/', feel free to ignore the second patch.

Cheers, Trevor

[1]: http://permalink.gmane.org/gmane.comp.version-control.git/48540
W. Trevor King (2):
  notes get-ref: --expand expands the output notes ref.
  notes: don't alter refs starting with 'refs/' in expand_notes_ref
 Documentation/git-notes.txt |  6 +++++-
 builtin/notes.c             | 26 +++++++++++++++++++++-----
 notes.c                     |  2 +-
 t/t3301-notes.sh            | 12 ++++++++++++
 4 files changed, 39 insertions(+), 7 deletions(-)
-- 
1.7.12.176.g3fc0e4c.dirty
W. Trevor King· Sep 5, 2012, 12:52 UTC · re: W. Trevor King · lore

[PATCH 1/2] notes get-ref: --expand expands the output notes ref.

From: "W. Trevor King" <wking@tremily.us>
Useful for debugging refs that don't seem to be expanding correctly.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
 Documentation/git-notes.txt |  6 +++++-
 builtin/notes.c             | 26 +++++++++++++++++++++-----
 t/t3301-notes.sh            |  8 ++++++++
 3 files changed, 34 insertions(+), 6 deletions(-)
Show changes to 3 files +34 −6

Documentation/git-notes.txt, builtin/notes.c, t/t3301-notes.sh

diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index b95aafa..a93d211 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -19,7 +19,7 @@ SYNOPSIS
 'git notes' merge --abort [-v | -q]
 'git notes' remove [--ignore-missing] [--stdin] [<object>...]
 'git notes' prune [-n | -v]
-'git notes' get-ref
+'git notes' get-ref [-e]
 
 
 DESCRIPTION
@@ -165,6 +165,10 @@ OPTIONS
 	input (there is no reason you cannot combine this with object
 	names from the command line).
 
+-e::
+--expand::
+  Expand the notes ref before printing it.
+
 -n::
 --dry-run::
 	Do not remove anything; just report the object names whose notes
diff --git a/builtin/notes.c b/builtin/notes.c
index 3644d14..17c6136 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -31,7 +31,7 @@ static const char * const git_notes_usage[] = {
 	"git notes merge --abort [-v | -q]",
 	"git notes [--ref <notes_ref>] remove [<object>...]",
 	"git notes [--ref <notes_ref>] prune [-n | -v]",
-	"git notes [--ref <notes_ref>] get-ref",
+	"git notes [--ref <notes_ref>] get-ref [-e]",
 	NULL
 };
 
@@ -84,7 +84,7 @@ static const char * const git_notes_prune_usage[] = {
 };
 
 static const char * const git_notes_get_ref_usage[] = {
-	"git notes get-ref",
+	"git notes get-ref [<options>]",
 	NULL
 };
 
@@ -1046,16 +1046,32 @@ static int prune(int argc, const char **argv, const char *prefix)
 
 static int get_ref(int argc, const char **argv, const char *prefix)
 {
-	struct option options[] = { OPT_END() };
+	const char *ref;
+	struct strbuf buf = STRBUF_INIT;
+	int expand = 0;
+	struct option options[] = {
+		OPT_BOOL('e', "expand", &expand,
+		         "expand the notes ref before printing it"),
+		OPT_END()
+	};
 	argc = parse_options(argc, argv, prefix, options,
 			     git_notes_get_ref_usage, 0);
 
-	if (argc) {
+	if (argc > 1) {
 		error("too many parameters");
 		usage_with_options(git_notes_get_ref_usage, options);
 	}
 
-	puts(default_notes_ref());
+	ref = default_notes_ref();
+	if (expand) {
+		strbuf_insert(&buf, 0, ref, strlen(ref));
+		expand_notes_ref(&buf);
+		puts(buf.buf);
+		strbuf_release(&buf);
+	} else {
+		puts(ref);
+	}	
+
 	return 0;
 }
 
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index 16de05a..c0486a0 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -1222,4 +1222,12 @@ test_expect_success 'git notes get-ref (--ref)' '
 	test "$(GIT_NOTES_REF=refs/notes/bar git notes --ref=baz get-ref)" = "refs/notes/baz"
 '
 
+test_expect_success 'git notes get-ref (no expand)' '
+	test "$(GIT_NOTES_REF=commits git notes get-ref)" = "commits"
+'
+
+test_expect_success 'git notes get-ref (--expand)' '
+	test "$(GIT_NOTES_REF=commits git notes get-ref --expand)" = "refs/notes/commits"
+'
+
 test_done

-- 
1.7.12.176.g3fc0e4c.dirty
Johan Herland· Sep 5, 2012, 15:49 UTC · re: W. Trevor King · lore

Re: [PATCH 1/2] notes get-ref: --expand expands the output notes ref.

On Wed, Sep 5, 2012 at 2:52 PM, W. Trevor King <wking@tremily.us> wrote:
Show 5 quoted lines
> From: "W. Trevor King" <wking@tremily.us>
>
> Useful for debugging refs that don't seem to be expanding correctly.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
Acked-by: Johan Herland <johan@herland.net>
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Junio C Hamano· Sep 6, 2012, 05:23 UTC · re: Johan Herland · lore

Re: [PATCH 1/2] notes get-ref: --expand expands the output notes ref.

Johan Herland <johan@herland.net> writes:
Show 8 quoted lines
> On Wed, Sep 5, 2012 at 2:52 PM, W. Trevor King <wking@tremily.us> wrote:
>> From: "W. Trevor King" <wking@tremily.us>
>>
>> Useful for debugging refs that don't seem to be expanding correctly.
>>
>> Signed-off-by: W. Trevor King <wking@tremily.us>
>
> Acked-by: Johan Herland <johan@herland.net>
Really?  Would "git log --expand master" be useful?

I'd have to say that a DWIM that the user needs to diagnose with such a "feature" is a total failure. Can't we fix that root cause instead?

That is, for a name, e.g. "refs/remotes/origin/notes/commit" (the original example in [PATCH 0/2]) or "commit" (the usual):

 - If it is already a ref, just use that (e.g. use that stuff in the
   refs/remotes/ hierarchy); or
 - If it is not, prefix refs/notes/ to it.
or something?
W. Trevor King· Sep 6, 2012, 06:11 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] notes get-ref: --expand expands the output notes ref.

On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
> Really?  Would "git log --expand master" be useful?
I'm clearly not an expert on this, but isn't that what
  git show-ref master

is for? Or is the fact that show-ref returns hashes the more important feature?

There was a lot of "ambiguous refs" discussion in the follow-up for
  http://thread.gmane.org/gmane.comp.version-control.git/165885
  Subject: [1.8.0] Provide proper remote ref namespaces
For example:
On Mon, Feb 07, 2011 at 03:25:51PM -0500, Jeff King wrote:
Show 6 quoted lines
> Will the same apply to refs/heads/foo versus refs/remotes/*/foo? Will it
> also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the
> final case, that does matter to "git push" (should the destination be in
> the head or tag namespace?). So the actual names of the ref can matter,
> and should probably be taken into account when deciding what is
> ambiguous.

So it seems like having a way to figure out how Git is interpreting a shorthand ref would be useful, especially while those of us with less experience are learning to think like Git.

The expansion command doesn't have to be notes-specific, but since the current ref expansion is role specific (e.g. branch/tag/note/…), it seemed like the best place to put it. With more consistent ref interpretation, I'd be less interested in this expansion command ;).

Trevor
-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Junio C Hamano· Sep 6, 2012, 19:47 UTC · re: W. Trevor King · lore

Re: [PATCH 1/2] notes get-ref: --expand expands the output notes ref.

"W. Trevor King" <wking@tremily.us> writes:
Show 8 quoted lines
> On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
>> Really?  Would "git log --expand master" be useful?
>
> I'm clearly not an expert on this, but isn't that what
>
>   git show-ref master
>
> is for?

But then can't you say the same against "git notes get-ref --expand" with "git show-ref refs/remotes/origin/notes/foobla"?

My primary point is that I think it is a UI mistake if the DWIM ignores the user input that directly names that can be interpreted without DWIMming. When the user wants to avoid ambiguity, it should always be possible to spell it out without having to worry about the DWIM code to get in the way.

The problem with the current notes.c:expand_notes_ref() is that it does not allow you to do that, and if you fixed that problem, the user never has to ask "what does this expand to", no?

Perhaps something like this. Note that this only deals with an existing ref, and that is semi-deliberate (because I am not yet convinced that it is a good idea to let any ref outside refs/notes/ to be created to hold a notes tree).

 notes.c | 2 ++
 1 file changed, 2 insertions(+)
Show changes to diff +2 −0
diff --git i/notes.c w/notes.c
index 93e9868..126839e 100644
--- i/notes.c
+++ w/notes.c
@@ -1289,6 +1289,8 @@ int copy_note(struct notes_tree *t,
 
 void expand_notes_ref(struct strbuf *sb)
 {
+	if (!prefixcmp(sb->buf, "refs/") && ref_exists(sb->buf))
+		return;
 	if (!prefixcmp(sb->buf, "refs/notes/"))
 		return; /* we're happy */
 	else if (!prefixcmp(sb->buf, "notes/"))
Johan Herland· Sep 10, 2012, 20:21 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] notes get-ref: --expand expands the output notes ref.

On Thu, Sep 6, 2012 at 9:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 27 quoted lines
> "W. Trevor King" <wking@tremily.us> writes:
>> On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
>>> Really?  Would "git log --expand master" be useful?
>>
>> I'm clearly not an expert on this, but isn't that what
>>
>>   git show-ref master
>>
>> is for?
>
> But then can't you say the same against "git notes get-ref --expand"
> with "git show-ref refs/remotes/origin/notes/foobla"?
>
> My primary point is that I think it is a UI mistake if the DWIM
> ignores the user input that directly names that can be interpreted
> without DWIMming.  When the user wants to avoid ambiguity, it should
> always be possible to spell it out without having to worry about the
> DWIM code to get in the way.
>
> The problem with the current notes.c:expand_notes_ref() is that it
> does not allow you to do that, and if you fixed that problem, the
> user never has to ask "what does this expand to", no?
>
> Perhaps something like this.  Note that this only deals with an
> existing ref, and that is semi-deliberate (because I am not yet
> convinced that it is a good idea to let any ref outside refs/notes/
> to be created to hold a notes tree).
(sorry for the late reply; I was away this weekend)

This patch looks like an acceptable solution to me. Especially since it prevents the notes code from "accidentally" creating new notes trees outside refs/notes/*.

That said, we should check for more cases of hardcoded "refs/notes/" that potentially needs changing as well.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
W. Trevor King· Sep 5, 2012, 12:52 UTC · re: W. Trevor King · lore

[PATCH 2/2] notes: don't alter refs starting with 'refs/' in expand_notes_ref

From: "W. Trevor King" <wking@tremily.us>
This avoids surprising cases like:
  $ GIT_NOTES_REF=refs/remotes/origin/notes/commits git notes get-ref --expand
  refs/notes/refs/remotes/origin/notes/commits

With the old implementation, all note refs had to live under 'refs/notes/' which was not mentioned in the git-notes.txt.

Signed-off-by: W. Trevor King <wking@tremily.us>
---
 notes.c          | 2 +-
 t/t3301-notes.sh | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)
Show changes to 2 files +5 −1

notes.c, t/t3301-notes.sh

diff --git a/notes.c b/notes.c
index 93e9868..60394c8 100644
--- a/notes.c
+++ b/notes.c
@@ -1289,7 +1289,7 @@ int copy_note(struct notes_tree *t,
 
 void expand_notes_ref(struct strbuf *sb)
 {
-	if (!prefixcmp(sb->buf, "refs/notes/"))
+	if (!prefixcmp(sb->buf, "refs/"))
 		return; /* we're happy */
 	else if (!prefixcmp(sb->buf, "notes/"))
 		strbuf_insert(sb, 0, "refs/", 5);
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index c0486a0..707d7e6 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -1230,4 +1230,8 @@ test_expect_success 'git notes get-ref (--expand)' '
 	test "$(GIT_NOTES_REF=commits git notes get-ref --expand)" = "refs/notes/commits"
 '
 
+test_expect_success 'git notes get-ref (--expand)' '
+	test "$(GIT_NOTES_REF=refs/remotes/origin/notes/commits git notes get-ref --expand)" = "refs/remotes/origin/notes/commits"
+'
+
 test_done

-- 
1.7.12.176.g3fc0e4c.dirty
Johan Herland· Sep 5, 2012, 15:58 UTC · re: W. Trevor King · lore

Re: [PATCH 0/2] Add --expand to 'git notes get-ref'

On Wed, Sep 5, 2012 at 2:48 PM, W. Trevor King <wking@tremily.us> wrote:
Show 10 quoted lines
> The second commit makes the expansion less strict about the location
> of note refs.  In his initial mail introducing 'git notes', Johan says
> that note refs should live under 'refs/notes' [1].  This seems like a
> good place for local notes, but note refs from remote repos should
> probably live somewhere else (e.g. 'refs/remote-notes/' or
> 'refs/remotes/<name>/notes/'.  In the initial thread there are a few
> messages talking about looking up reverse mappings under 'refs/notes/',
> but this seems to all have been before the 'refs/notes/<namespace>/'
> stage.  If I'm missing a good reason to keep everything under
> 'refs/notes/', feel free to ignore the second patch.

This has been discussed a couple of times on this list, but it never resulted in any actual changes. Read up on this thread to get some context:

http://thread.gmane.org/gmane.comp.version-control.git/160503
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
W. Trevor King· Sep 5, 2012, 17:53 UTC · re: Johan Herland · lore

Re: [PATCH 0/2] Add --expand to 'git notes get-ref'

On Wed, Sep 05, 2012 at 05:58:37PM +0200, Johan Herland wrote:
Show 9 quoted lines
> On Wed, Sep 5, 2012 at 2:48 PM, W. Trevor King <wking@tremily.us> wrote:
> > If I'm missing a good reason to keep everything under
> > 'refs/notes/', feel free to ignore the second patch.
> 
> This has been discussed a couple of times on this list, but it never
> resulted in any actual changes. Read up on this thread to get some
> context:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/160503

Thanks for the pointer, it looks like there are a bunch of good ideas. I assume the lack of changes was due to nobody having the time/inclination to implement

  http://article.gmane.org/gmane.comp.version-control.git/160655
Trevor
-- 
As a side note, does anyone know of a thread-specific version of

  http://download.gmane.org/<xyz>/<start>/<stop>

It would be easier for me (and less load for them) if I could run

  http://download.gmane.org/gmane.comp.version-control.git/thread/160503

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Johan Herland· Sep 5, 2012, 22:44 UTC · re: W. Trevor King · lore

Re: [PATCH 0/2] Add --expand to 'git notes get-ref'

On Wed, Sep 5, 2012 at 7:53 PM, W. Trevor King <wking@tremily.us> wrote:
Show 16 quoted lines
> On Wed, Sep 05, 2012 at 05:58:37PM +0200, Johan Herland wrote:
>> On Wed, Sep 5, 2012 at 2:48 PM, W. Trevor King <wking@tremily.us> wrote:
>> > If I'm missing a good reason to keep everything under
>> > 'refs/notes/', feel free to ignore the second patch.
>>
>> This has been discussed a couple of times on this list, but it never
>> resulted in any actual changes. Read up on this thread to get some
>> context:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/160503
>
> Thanks for the pointer, it looks like there are a bunch of good ideas.
> I assume the lack of changes was due to nobody having the
> time/inclination to implement
>
>   http://article.gmane.org/gmane.comp.version-control.git/160655

Yes, I think time/inclination probably has a lot to do with it. Also, I forgot to link to the largest mailing list thread that discusses these changes in _much_ more detail:

http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165885

As you can see, the discussion quickly balloons into something much larger than a simple discussion of where remote notes should be located...

That said, your patch 2/2 might be an acceptable stopgap measure for the time being, and then we can reevaluate it if/when we implement a larger ref restructuring.

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

← back to recent threads