git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing list <git@vger.kernel.org>
Subject: Re: [PATCH v2] doc: clarify that "git bisect" accepts one or more good commits
Date: Fri, 24 Nov 2017 04:11:06 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.21.1711240351170.30318@localhost.localdomain> (raw)
In-Reply-To: <xmqqh8tkp9nn.fsf@gitster.mtv.corp.google.com>

On Fri, 24 Nov 2017, Junio C Hamano wrote:

> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:

... snip ...

> > -to indicate that it was after.
> > +to indicate a single commit after that change.
>
> As to "identify", I would say it is better to consistently use
> "indicate" like the original of these two hunks at the end says,
> i.e. "indicate that it is bad/new (or they are good/old)".

  i'm going to ponder this, but let me explain why i am such an
annoying stickler for the choice of words at times, and you can read
all about it here:

  http://twain.lib.virginia.edu/projects/rissetto/offense.html

in particular, i draw your attention to twain's trashing of cooper
for, in many cases, using *almost* the right word, but not *quite* the
right word:

"Cooper's word-sense was singularly dull. When a person has a poor ear
for music he will flat and sharp right along without knowing it. He
keeps near the tune, but is not the tune. When a person has a poor ear
for words, the result is a literary flatting and sharping; you
perceive what he is intending to say, but you also perceive that he
does not say it. This is Cooper. He was not a word-musician. His ear
was satisfied with the approximate words. I will furnish some
circumstantial evidence in support of this charge. My instances are
gathered from half a dozen pages of the tale called "Deerslayer." He
uses "Verbal" for "oral"; "precision" for "facility"; "phenomena" for
"marvels"; "necessary" for "predetermined"; "unsophisticated" for
"primitive"; "preparation" for "expectancy"; "rebuked" for "subdued";
"dependent on" for "resulting from"; "fact" for "condition"; "fact"
for "conjecture"; "precaution" for "caution"; "explain" for
"determine"; "mortified" for "disappointed"; "meretricious" for
"factitious"; "materially" for "considerably"; "decreasing" for
"deepening"; "increasing" for "disappearing"; "embedded" for
"inclosed"; "treacherous" for "hostile"; "stood" for "stooped";
"softened" for "replaced"; "rejoined" for "remarked"; "situation" for
"condition"; "different" for "differing"; "insensible" for
"unsentient"; "brevity" for "celerity"; "distrusted" for "suspicious";
"mental imbecility" for "imbecility"; "eyes" for "sight";
"counteracting" for "opposing"; "funeral obsequies" for "obsequies."

  in this sense, i don't think "indicate" and "identify" are
completely interchangeable. in my mind, the word "identify" does
nothing more than, you know, point at something and say, "that one,
that's the one i'm talking about;" it goes no further than that.

  on the other hand, the word "indicate" (in my mind) implies that
you're about to provide some *property* or *quality* of something, and
you do exactly that in the earlier quote:

> As to "identify", I would say it is better to consistently use
> "indicate" like the original of these two hunks at the end says,
> i.e. "indicate that it is bad/new (or they are good/old)".

  as in, you "identify" a commit, but you "indicate" that it
represents a good or bad commit. i know this sounds picky, but it is
exactly this tendency of using *almost* the right word that makes a
lot of documentation potentially confusing. given this distinction,
depending on the word to be used, i would write one of:

1) "first, identify the bad commit and one or more good commits..."

2) "first, indicate which commit is the bad commit, and which commits
are the good commits ..."

  the eventual meaning *should* be the same, but the choice of words
can make the meaning clear, or can confuse the reader.

  thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

  reply	other threads:[~2017-11-24  9:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22 12:32 [PATCH v2] doc: clarify that "git bisect" accepts one or more good commits Robert P. J. Day
2017-11-24  4:45 ` Junio C Hamano
2017-11-24  9:11   ` Robert P. J. Day [this message]
2017-11-24 13:27     ` Junio C Hamano
2017-11-24 14:07       ` 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=alpine.LFD.2.21.1711240351170.30318@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).