Re: [PATCH 1/2] notes get-ref: --expand expands the output notes ref.
- From
Johan Herland <johan@herland.net>
- Date
- Sep 10, 2012, 20:21 UTC
- Message-ID
- <CALKQrgen5r-VPp2mX7Yyiudx2+n1b_oK6iF57SWQ0o394Lm+Fg@mail.gmail.com>
- In-Reply-To
- <7vr4qf2atd.fsf@alter.siamese.dyndns.org>
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