From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: "gitster@pobox.com" <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
"mh@glandium.org" <mh@glandium.org>,
"mhagger@alum.mit.edu" <mhagger@alum.mit.edu>,
"johan@herland.net" <johan@herland.net>,
"jacob.keller@gmail.com" <jacob.keller@gmail.com>
Subject: Re: [PATCH] notes: document behavior of --ref and --notes DWIMery
Date: Tue, 22 Sep 2015 21:02:42 +0000 [thread overview]
Message-ID: <1442955762.26280.49.camel@intel.com> (raw)
In-Reply-To: <xmqq8u7y2nnq.fsf@gitster.mtv.corp.google.com>
On Tue, 2015-09-22 at 13:40 -0700, Junio C Hamano wrote:
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
> > From: Jacob Keller <jacob.keller@gmail.com>
> >
> > The --notes and --ref parameter for selecting which notes ref to
> > operate
> > on are based off of expand_notes_ref functionality. The
> > documentation
> > mentioned that an unqualified ref argument would be taken as under
> > `refs/notes/`. However, this does not clearly indicate that
> > `refs/heads/master` will expand to `refs/notes/refs/heads/master`,
> > so
> > document this behavior.
> >
> > Add a further test for the expected behavior of git notes --ref
> > refs/heads/master get-ref as well, to ensure future patches do not
> > break
> > this assumption.
> >
> > Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
> > ---
>
> Looks OK to a cursory read, but I find "even if it is qualified
> under some other location" a bit tiring to read without adding much
> value. To readers who consider "other" in that phrase to be clear
> enough (i.e. "location other than refs/notes"), it is totally
> redundant. To other readers who feel "other" in that phrase to be
> under qualified (i.e. "location other than what???"), it is not
> informative enough. Middle-ground readers who would not know if
> "refs/a" is inside or outside some "other" location, it is confusing.
>
> After all, "a/b" is qualified under some location (i.e. a/) other
> than "refs/notes/", and it does mean "refs/notes/a/b".
>
> How about phrasing it totally differently?
>
> The ref specifies the full refname when it begins with
> `refs/notes/`; otherwise `ref/notes/` is prefixed to form a
> full name of the ref.
>
> I think that would remove the need to illustrate with concrete
> examples like refs/heads/blah.
>
Yes, let's go with that.
Regards,
Jake
next prev parent reply other threads:[~2015-09-22 21:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 20:24 [PATCH] notes: document behavior of --ref and --notes DWIMery Jacob Keller
2015-09-22 20:40 ` Junio C Hamano
2015-09-22 21:02 ` Keller, Jacob E [this message]
2015-09-22 21:03 ` Keller, Jacob E
2015-09-22 21:23 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1442955762.26280.49.camel@intel.com \
--to=jacob.e.keller@intel.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jacob.keller@gmail.com \
--cc=johan@herland.net \
--cc=mh@glandium.org \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).