Jonathan Nieder <jrnie...@gmail.com> writes: > Ramkumar Ramachandra wrote: > >> I would say the most technically accurate >> description of what 'git log' takes is a "committish range" (basically >> a "revision range" that resolves to commits). > > What is a revision range that doesn't resolve to commits? Am I wrong > in thinking revision is nothing more than a synonym for commit? > > When gitrevisions(7) says "A revision parameter <rev> typically, but > not necessarily, names a commit object", I suspect it is residue from > 3a45f625 trying to apologize for the extended SHA1 syntax parser being > called "git rev-parse" instead of "git object-name-parse".
- A revision range is a slice of history. There is no need for "committish revision range" as there is no other kinds of ranges. - 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. - Documentation/revisions.txt needs to be cleaned up. It lists "specifying revisions" and "specifying ranges", which is a good start primarily because some notations used in ranges are not revisions (e.g. "^C"), but it should have three (not two) sections. They are: "specifying revisions", "specifying object names", and "specifying ranges". Move non committish specification such as <revision>:<path> from the current "specifying revisions" section and make the new "object names" section. The "ranges" section is already written in terms of revisions, and does not need any update, once we clarify the definition of a "revision" as "committish". -- 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
