W dniu 21.09.2016 o 18:50, Junio C Hamano pisze: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> There's surely room for improvement here, but I just wanted to address >> the very common case of sticking "git describe" output into commit >> messages without trying to link to all possible refnames, that's going >> to be a rather futile exercise given that this is free text, and it >> would be prohibitively expensive to look up whether the references in >> question exist in our repository. > > When I saw 2/3 I wondered about one thing and 3/3 shares the same, > which is that we only use regex match and do not validate for a > false match. Would it be too expensive to pick up what _looks_ like > a rev (e.g. hex or g(refname regexp)-hex) then validate it with > "rev-parse --verify --quiet" to make sure it is a rev, before > actually making it a link? Even if are we trying to account for > people referring to commits that do not exist in this repository > (e.g. some other project, in a submodule repository, or just an > earlier incarnation of rebasing that has since been lost), it seems > to me that it does not help to mark them with a link that won't > resolve. I think it could be a good *option*, but revision verification could be costly, for example in the 'log' view with multiple commits and multiple revision-like looking candidates, even if we were able to do it with one command. Also, "git rev-parse --verify [--quiet]" can verify only one revision at once, isn't it? Maybe something like 'git cat-file --batch-check' would be better (one fork)? It's a matter of balance between false positives (and unresolving links) and performance... Best, -- Jakub Narębski