Docs: Link to rendered GitHub AsciiDoc for release notes

[gaurav219]

Changes

• This PR updates those URLs to the raw release notes so that they appear well formatted, making them easier to read for contributors and users.

Files Changed

• hugo.yml
• script/update-git-version.rb
• layouts/shortcodes/install-header.html

Example before:
https://github.com/git/git/raw/HEAD/Documentation/RelNotes/2.52.0.adoc

Example after:
https://gitlab.com/git-scm/git/-/blob/v2.52.0/Documentation/RelNotes/2.52.0.adoc

Context

The existing release notes URLs reference the raw AsciiDoc files on raw.githubusercontent.com, which renders as plain text without formatting. As a result, the release notes are harder to read.

This update replaces those raw URLs with links to the rendered AsciiDoc view on the GitLab mirror, making the release notes more readable and user-friendly. The links now reference the tagged version (v2.52.0) to ensure they remain stable and accurately reflect the contents of the 2.52.0 release.

[dscho]

Thank you for working on this @gaurav219! A few changes are necessary before it can be merged, though.

[dscho]

This will break for later versions: You are hard-coding v2.52.0 as the revision in which to look for the release notes. Naturally, this revision only contains the release notes leading up to that version, and once, say, v2.52.1 or v2.53.0 come out, the updated link will 404 because the v2.52.0 revision won't magically change to include the release notes for those new versions.

You need to either replace v2.52.0 by v#{version} (and understand what that is doing), or do the equivalent from before, i.e. point to https://gitlab.com/git-scm/git/-/blob/HEAD/Documentation/RelNotes/2.52.0.adoc.

[dscho]

Please lose this white-space only change that is totally unrelated to what the commit message says.

Speaking of the commit message: It really wants to see some love. From looking at the oneliner "Docs: Link to rendered GitHub AsciiDoc for release notes", I am almost 100% certain that even you, in 6 months from now, would have trouble to deduce why you made the change. But that's vital information! And the only spot where you can reliably store that information for later reference is the commit message. In general, it is a poor idea to use one-liners as commit messages. A much better idea is described here, in particular the part that recommends to ensure that the commit message covers these four axes:

	What you’re doing	Why you’re doing it
High-level (strategic)	Intent (what does this accomplish?)	Context (why does the code do what it does now?)
Low-level (tactical)	Implementation (what did you do to accomplish your goal?)	Justification (why is this change being made?)

[dscho]

Here, too, the hard-coded v2.52.0 revision would come back to bite you, if merged unchanged.

The natural fix would be to replace it by HEAD.

But a more fundamental question that should immediately come to your mind when you make virtually the same change in two separate places (the href value in install-header.html as well as the latest_relnote_url value in update-git-version.rb): Why is this URL defined in two separate locations? That's redundant.

In this particular instance, the obvious question is: if update-git-version.rb goes out of its way to define a global parameter latest_relnote_url in addition to latest_version, why on Earth is that latest_relnote_url parameter not used here?

Paying attention to such details and acting on them while you develop patches will automatically improve the quality of your work by ten times, I am sure.