From: Ramkumar Ramachandra Date: Sun, 21 Apr 2013 09:05:46 GMT Subject: Re: [PATCH 4/5] git-log.txt: rewrite note on why "--" may be required Message-ID: 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. > - 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?