"W. Trevor King" <wk...@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).
notes.c | 2 ++
1 file changed, 2 insertions(+)
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/"))
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
