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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html