ZheNing Hu <adlternative@xxxxxxxxx> writes:
>> --verify
>> Verify that exactly one parameter is provided, and that it
>> can be turned into a raw 20-byte SHA-1 that can be used to access the
>> object database. If so, emit it to the standard output;
>> otherwise, error out.
>>
>
> So why doesn't "git rev-list --verify" check if 20-byte SHA-1 can
> "access the object database"?
Hysterical Raisins.
"rev-parse" can do many things, and one of them is about expanding
strings (like "9e4df4da", "jt/path-filter-fix", "seen~7^2", and
"9e4df4da0786797b1d51ed8fd3dfc18970772a91") given from the command
line into hexadecimal strings of the full length (they are often
called "revision"). "--verify" tells the command that on the
command line there must be ONE and only one "revision", give the
full length hexadecimal string for it. The command fails if the
command line argument cannot be turned into a hexadecimal string of
the full length.
Now, among the ones given as examples in the above, "9e4df4da",
needs to look at the object database to turn it into a hexadecimal
string of the full length, because it is likely to be an abbrevation
(although it could be a branch name, too). "jt/path-filter-fix" and
"seen~7^2" needs to look at the refs and probably into the object
database (to see what the 7th generation grandparent is and what the
second parent of that commit is) before they can be turned into
hexadecimal strings of the full length.
But "9e4df4da0786797b1d51ed8fd3dfc18970772a91" is already a full
hexadecimal, so it is given back as a "revision" without checking if
there is such an object in the object database.
Checking if it can be turned into the form that can be used to query
the object database, and checking the object database using it to
find out if such an object exists, are two distinct steps low-level
tool authors, who would want to use the plumbing tools, may need.
The current option set allows the separation (and ^{object} suffix
lets you do the both at the same time, too).
