On Thu, Sep 6, 2012 at 9:47 PM, Junio C Hamano <gits...@pobox.com> wrote:
> "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).
(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 Herland, <jo...@herland.net>
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