On 03/14/2017 11:07 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 03/14/2017 10:32 AM, Tom Lane wrote:
>>> +1 for commitdiff, that's pretty much always the form of the page I want
>>> to see.
>> Done.
> Thanks for changing that, it's definitely helpful.
>
> I'm a bit confused about the links for the "files changed this run"
> list. What they seem to be now is pointers to the last commit that
> changed each file. I might be misremembering, but I thought they
> had been links to the individual files in our git tree. As long
> as we're fooling around here, it seems like links to the per-file
> history logs would be convenient; eg instead of
>
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a82178020de2c4b3576d0a079e11a431e382e4de
>
> which is the link being offered right now for
> src/backend/optimizer/plan/createplan.c in recent runs, perhaps
>
>
https://git.postgresql.org/gitweb/?p=postgresql.git;a=history;f=src/backend/optimizer/plan/createplan.c;h=4629ca27ee559086929daf437ac5e6954b1987d6
>
> That particular display is useful since it's easy to get to either
> the raw file contents ("blob") or the relevant commitdiffs from there.
> However, fooling with it, it seems that the blob links don't get offered
> unless the "h=" hash is the file's hash, not the commit's hash. (gitweb
> bug?) That might make it too hard to do, dunno. A close second in
> usefulness would be to use the commit's hash,
>
>
https://git.postgresql.org/gitweb/?p=postgresql.git;a=history;f=src/backend/optimizer/plan/createplan.c;h=a82178020de2c4b3576d0a079e11a431e382e4de
>
>
It's pretty much always been this way, pointing to the most recent
relevant commit.
Originally, the server knew nothing of git refs (or CVS revision
numbers) at all. It just took information from the client about versions
of each file and shoved it into a URL, and the client code has always
pointed to the most recent revision in the relevant time period.
We could do a lot better than that now, as we know the git commit ref
for each snapshot, and the server keeps a pretty up to data mirror of
the code.
I agree it would be nice to get a history for the file for the relevant
period. I didn't really like either of your suggestions, though, because
they are showing a lot more history that I want to see.
However, there's more work there than just a line or two to change, so
it's going to take a bit of time to get right.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services