All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/6] Documentation/git-merge.txt: improve short description in DESCRIPTION
Date: Thu, 06 Oct 2016 15:30:57 +0300	[thread overview]
Message-ID: <87mvihpsla.fsf@javad.com> (raw)
In-Reply-To: <xmqqa8eio4n9.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Wed, 05 Oct 2016 14:41:14 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> OK, I see. So, what is the best way to handle this? Immediately follow
>> content change patch with another patch that only re-flows?
>
> Or no reflowing at all.
>
>>> the parents".  I do not know if the updated phrasing is better.  The
>>> "name" in the original was meant to be a short-hand for "object name",
>>> and I would support a change to spell it out to clarify; "reference"
>>> can be a vague word that can mean different things in Git, and when
>>> the word is given without context, most Git people would think that
>>> the word refers to "refs", but that is definitely not what the new
>>> commit records, so...
>>
>> I won't insist on the change, but "name" sounded wrong to me, and
>> "reference" was most general term I was able to come up with in this
>> context.
>> ...
>> Last, if "reference" is not good enough and we get to internals anyway,
>> why not say SHA1 then?
>
> Because that is still colloquial? I think s/name/object name/ is a
> sensible change, but not s/name/reference/.

No, "reference" is more sensible here than any of "name", "object name",
or "SHA-1", the same way as here:

$ git help glossary
[...]
chain
        A list of objects, where each object in the list contains a
        reference to its successor (for example, the successor of a
        commit could be one of its parents).
[...]
$

The resulting merge commit is an origin for 2 chains, so it stores 2
references to its successors. No need to be aware of any [object] names
to understand all this.

-- Sergey

  reply	other threads:[~2016-10-06 12:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05 14:46 [PATCH 0/6] git-merge: a few documentation improvements sorganov
2016-10-05 14:46 ` [PATCH 1/6] git-merge: clarify "usage" by adding "-m <msg>" sorganov
2016-10-05 17:46   ` Junio C Hamano
2016-10-05 20:41     ` Sergey Organov
2016-10-05 14:46 ` [PATCH 2/6] Documentation/git-merge.txt: remove list of options from SYNOPSIS sorganov
2016-10-05 17:47   ` Junio C Hamano
2016-10-05 21:03     ` Sergey Organov
2016-10-05 14:46 ` [PATCH 3/6] Documentation/git-merge.txt: fix SYNOPSIS of obsolete form to include options sorganov
2016-10-05 14:46 ` [PATCH 4/6] Documentation/git-merge.txt: improve short description in NAME sorganov
2016-10-05 17:52   ` Junio C Hamano
2016-10-05 21:01     ` Sergey Organov
2016-10-05 17:55   ` Jeff King
2016-10-05 20:44     ` Sergey Organov
2016-10-05 14:46 ` [PATCH 5/6] Documentation/git-merge.txt: improve short description in DESCRIPTION sorganov
2016-10-05 16:58   ` Jakub Narębski
2016-10-05 20:01     ` Junio C Hamano
2016-10-05 21:27     ` Sergey Organov
2016-10-06 13:21     ` Sergey Organov
2016-10-05 18:07   ` Junio C Hamano
2016-10-05 21:24     ` Sergey Organov
2016-10-05 21:41       ` Junio C Hamano
2016-10-06 12:30         ` Sergey Organov [this message]
2016-10-06 17:46           ` Junio C Hamano
2016-10-07 13:13             ` Sergey Organov
2016-10-05 14:46 ` [PATCH 6/6] Documentation/git-merge.txt: get rid of irrelevant references to git-pull sorganov
2016-10-05 18:57   ` Junio C Hamano
2016-10-05 21:34     ` Sergey Organov
2016-10-05 21:43       ` Junio C Hamano
2016-10-06 12:39         ` Sergey Organov
2016-10-06 18:06           ` Junio C Hamano
2016-10-07 11:45             ` Sergey Organov

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=87mvihpsla.fsf@javad.com \
    --to=sorganov@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.