Re: [PATCH 4/5] git-log.txt: rewrite note on why "--" may be required

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 21, 2013, 09:05 UTC
Message-ID: <CALkWK0nHbm4La4kJ6cNzEnMas5B7Q2M=z_9d+O6iNX2r2bi98A@mail.gmail.com>
In-Reply-To: <7vvc7guvu4.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

>  - A revision range is a slice of history.  There is no need for
>    "committish revision range" as there is no other kinds of ranges.

For the record, 'git rev-parse master:README..HEAD@{3}~2' works just fine. I don't know whether you want to consider it "sensible" or not, but the current revisions.txt is consistent with this.

Show 7 quoted lines

>  - A revision should be a synonym to a committish, as glossary
>    defines.  We historically used "revision" more or less
>    interchangeably with "object name", especially "an extended SHA-1
>    expression that is used as an object name", to mean whatever
>    get_sha1() can grok down to a single object name.  This must be
>    rectified to avoid causing confusion to new readers of our
>    documentation.

The question is: who is the authority on this? The combination of rev-parse, rev-list, and revisions.txt, or gitglossary.txt.

>    They are: "specifying revisions", "specifying object names", and
>    "specifying ranges".

Personally, I don't like giving commit objects a special status, and like things just the way they currently are. Why do you want to separate "revisions" (which are really just "extended SHA-1 expressions" that incidentally resolve to commit objects) and "extended SHA-1 expressions that resolve to objects other than commits"? Is the current hand-wavy unclear gitglossary.txt the only basis for your argument?