Re: rev-list and "ambiguous" IDs

[Jeff King <peff@peff.net>]

On Thu, Nov 14, 2019 at 05:19:39PM -0800, Bryan Turner wrote:

> Just to provide a little context, this isn't coming up as something I
> myself hit. Rather, it's a fairly common issue reported by Bitbucket
> Server end users, and I would assume it happens with other hosting
> providers as well: A user URL-hacks an ambiguous (or "ambiguous", in
> cases like this) short hash and is disappointed when the system
> doesn't manage to find the commit they were looking for. I'm just
> investigating possible avenues for improving how Bitbucket Server
> handles these cases. One option is to (essentially) parse the "hint",
> if it's present, to get the candidates, and include them on the error
> message we display. But in cases like the above it gets weird because
> there's only one _commit_ candidate, and having our error message
> include trees and blobs seems likely to be confusing/unexpected. I
> suspect most Bitbucket Server users would say "The answer's obvious!
> Why didn't you just use the commit?!", and I can sort of get behind
> that view. The combination of using the disambiguation mechanism, so
> single-commit ambiguities are resolved automatically, and parsing the
> hint seems like it would produce the most logical behavior.

It depends on your URL scheme obviously, but on GitHub for example, it
would make sense for https://github.com/user/repo/commit/1234abcd to use
the "^{commit}" trick. I don't think it currently does, though.

> Where users get the short hashes they try is an interesting question.
> As you say, Git wouldn't display a 5 character short hash, at least by
> default, and Bitbucket Server doesn't either; it shows a flat 11
> characters. I'm not sure, on that point.

GitHub often produces 7-char short hashes, because it's abbreviating
them in presentation code that doesn't want to spend the round trip to
talk to the repo (to find out if it's unique, or how many objects are in
the repo). It _usually_ shouldn't matter much, because we try to produce
abbreviated hashes where users might read them, and long hashes when we
generate URLs. But of course people sometimes generate URLs themselves
from who knows where. :) I've been lightly lobbying to bump our default
to something higher, like 12.

-Peff