I meant expose it as field for query so you can limit the query to sha1

This would probably require adding an index covering it, as it's currently not indexed at all (although img_sha1 is).

(In reply to comment #1)

I meant expose it as field for query so you can limit the query to sha1

Good thing you clarified, I was about to close this as a dup of bug 21860.

What exactly is the use case for this, that isn't served by processing the output of prop=revisions&rvprop=sha1 on the client?

(In reply to comment #2)

This would probably require adding an index covering it, as it's currently
not indexed at all (although img_sha1 is).

That is correct.

Sometimes there can be way too many revisions to practically loop through them all to find out which one is the oldest one. For example in a edit war/revert war, I would want to be able to quickly get the original revision which started it all, and of someone reverts to a really old revision, it's good to be able to quickly find out whom made that revision in case of sockery

afeldman wrote:

If rev_sha1 will always be queried with a page id, a (rev_page, rev_sha1(5)) index should be fine, even on enwiki.

Note that the sha1 returned by the api is not the rev_sha1 field of the revision table, but a sha1 of the sha1 :facepalm: ... see T75411 for all its glory.

So I think that would be really confusing, as the output sha1 of the prop=revisions can't be used to query it again for that particular sha1

I think it is the same value, just written differently. A SHA-1 hash is just a 160-bit number, which is usually displayed as 40 digits in base 16 (e.g. 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12), it can be written in any base. MediaWiki internally stores it as a human-readable value in base 36, presumably as a compromise between space taken and readability.

In T51136#1701966, @matmarex wrote:

I think it is the same value, just written differently.

You are correct.