On Thu, Sep 6, 2012 at 9:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "W. Trevor King" <wking@xxxxxxxxxx> 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@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html