Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages
- From
Jakub Narębski <jnareb@gmail.com>
- Date
- Sep 21, 2016, 17:49 UTC
- Message-ID
- <ba9d9c82-4b5e-4d62-95f1-a1c56cfc70af@gmail.com>
- In-Reply-To
- <xmqqvaxp9oyp.fsf@gitster.mtv.corp.google.com>
W dniu 21.09.2016 o 18:50, Junio C Hamano pisze:
Show 20 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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