[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-web PATCH v2] Use GitLab repo URLs instead of git.qemu.org URL

From: Thomas Huth
Subject: Re: [qemu-web PATCH v2] Use GitLab repo URLs instead of git.qemu.org URLs
Date: Thu, 14 Jan 2021 16:29:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3

On 14/01/2021 14.40, Stefan Hajnoczi wrote:
On Thu, Jan 14, 2021 at 10:42:59AM +0100, Thomas Huth wrote:
On 13/01/2021 19.54, Stefan Hajnoczi wrote:
Switch to GitLab repo URLs to reduce qemu.org bandwidth.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
   * Added missing URL in _posts/2018-06-28-tcg-testing.md. Mark
     Cave-Ayland <mark.cave-ayland@ilande.co.uk> and Alex Bennée
     <alex.bennee@linaro.org> figured out the issue was that the gitweb
     link referenced a blob object (not a commit) whereas GitLab needs the
     commit object. Therefore the hash hash in the URL has changed.
   _download/source.html                           | 4 ++--
   _posts/2017-02-04-the-new-qemu-website-is-up.md | 8 ++++----
   _posts/2017-10-04-qemu-2-10-1.md                | 4 ++--
   _posts/2018-02-09-understanding-qemu-devices.md | 2 +-
   _posts/2018-06-28-tcg-testing.md                | 4 ++--
   contribute.md                                   | 2 +-
   contribute/security-process.md                  | 4 ++--
   documentation.md                                | 2 +-
   support.md                                      | 2 +-
   9 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/_download/source.html b/_download/source.html
index 5798633..14fb6dc 100644
--- a/_download/source.html
+++ b/_download/source.html
@@ -9,7 +9,7 @@
        {% include releases.html %}
        <p>or stay on the bleeding edge with the
-          <a href="https://git.qemu.org/?p=qemu.git";>git repository!</a></p>
+          <a href="https://gitlab.com/qemu-project/qemu.git";>git 

For "clickable" links (i.e. not the URLs used for cloning), I'd suggest to
drop the ".git" suffix, since there will be a redirection to the suffix-less
URL otherwise.

If you agree, I can fix it up when picking up the patch, no need to resend
just because of this.

I don't have a strong opinion either way. I chose this approach because
it results in a clean git clone while also working in a web browser
(with a redirect, as you mentioned).

Ok, I've pushed your patch with some of the .git suffixes removed. I don't think that anybody will try to clone from a link where the link text is saying "git repository!" like in above source.html, so I removed it there. But in the instructions for running "git clone ...", I of course kept the suffix.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]