Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Johan Herland <hidden>
Date: 2016-06-15 22:54:43

On Thu, Sep 6, 2012 at 9:47 PM, Junio C Hamano [off-list ref] wrote:
"W. Trevor King" [off-list ref] writes:
quoted
On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
quoted
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, [off-list ref]
www.herland.net
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help