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.

>  - 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to