Switch links to https #1589
Closed
Switch links to https #1589
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/submit |
|
Submitted as pull.1589.git.1695392027.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
Documentation/CodingGuidelines
Outdated
| @@ -24,7 +24,7 @@ code. For Git in general, a few rough rules are: | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Eric Sunshine wrote (reply to this):
On Fri, Sep 22, 2023 at 10:14 AM Josh Soref via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> doc: switch links to https
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> #include "git-compat-util.h"
> --- a/json-writer.h
> +++ b/json-writer.h
> @@ -3,7 +3,7 @@
> /*
> * JSON data structures are defined at:
> - * [1] http://www.ietf.org/rfc/rfc7159.txt
> + * [1] https://www.ietf.org/rfc/rfc7159.txt
> * [2] http://json.org/
Shouldn't "json.org" receive the same s/http/https/ treatment?
|
User |
| @@ -518,7 +518,7 @@ For Perl programs: | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Eric Sunshine wrote (reply to this):
On Fri, Sep 22, 2023 at 10:14 AM Josh Soref via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> doc: update links to current pages
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> diff --git a/json-writer.h b/json-writer.h
> @@ -4,7 +4,7 @@
> /*
> * JSON data structures are defined at:
> * [1] https://www.ietf.org/rfc/rfc7159.txt
> - * [2] http://json.org/
> + * [2] https://www.json.org/
Not sure why this change is needed considering that the simpler
s/http/https/ seems sufficient.There was a problem hiding this comment.
On the Git mailing list, Josh Soref wrote (reply to this):
Eric Sunshine wrote:
> > doc: update links to current pages
> > @@ -4,7 +4,7 @@
> > - * [2] http://json.org/
> > + * [2] https://www.json.org/
>
> Not sure why this change is needed considering that the simpler
> s/http/https/ seems sufficient.
This is because that's their preference:
```sh
% curl -s http://json.org/|grep REFRESH
<meta HTTP-EQUIV="REFRESH" content="0;
url=https://www.JSON.org/json-en.html"></head>
```
It's somewhat traditional to respect sites' self-identification.There was a problem hiding this comment.
On the Git mailing list, Eric Sunshine wrote (reply to this):
On Fri, Sep 22, 2023 at 5:31 PM Josh Soref <jsoref@gmail.com> wrote:
> Eric Sunshine wrote:
> > > - * [2] http://json.org/
> > > + * [2] https://www.json.org/
> >
> > Not sure why this change is needed considering that the simpler
> > s/http/https/ seems sufficient.
>
> This is because that's their preference:
>
> ```sh
> % curl -s http://json.org/|grep REFRESH
> <meta HTTP-EQUIV="REFRESH" content="0;
> url=https://www.JSON.org/json-en.html"></head>
> ```
>
> It's somewhat traditional to respect sites' self-identification.
It might be worth calling that out in the commit message of both
patches if you happen to reroll so other reviewers understand the
motivation. (That said, on its own, it's probably not worth a reroll.)
|
User |
Documentation/CodingGuidelines
Outdated
| @@ -24,7 +24,7 @@ code. For Git in general, a few rough rules are: | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/CodingGuidelines | 2 +-
> Documentation/MyFirstContribution.txt | 2 +-
> Documentation/git-cvsimport.txt | 2 +-
> Documentation/git-format-patch.txt | 2 +-
> Documentation/git-imap-send.txt | 2 +-
> Documentation/git-send-email.txt | 2 +-
> Documentation/gitcore-tutorial.txt | 2 +-
> Documentation/gitprotocol-http.txt | 4 ++--
> Documentation/gitweb.conf.txt | 2 +-
> Documentation/gitweb.txt | 2 +-
> Documentation/howto/keep-canonical-history-correct.txt | 2 +-
> Documentation/signoff-option.txt | 2 +-
> INSTALL | 2 +-
> Makefile | 4 ++--
> README.md | 2 +-
These are end-user facing and most of the changes looked sensible,
except for URLs that had comments like "at the time of this writing
the URL is at ...", which we should not bother touching. There may
be other reasons not to touch some of them, but I didn't look very
closely.
> compat/nedmalloc/malloc.c.h | 10 +++++-----
> compat/obstack.c | 2 +-
> compat/obstack.h | 2 +-
> compat/poll/poll.c | 2 +-
> compat/poll/poll.h | 2 +-
> compat/precompose_utf8.h | 2 +-
> compat/regex/regcomp.c | 2 +-
> compat/regex/regex.c | 2 +-
> compat/regex/regex.h | 2 +-
> compat/regex/regex_internal.c | 2 +-
> compat/regex/regex_internal.h | 2 +-
> compat/regex/regexec.c | 2 +-
> compat/vcbuild/README | 10 +++++-----
> contrib/completion/git-completion.bash | 2 +-
> .../credential/libsecret/git-credential-libsecret.c | 2 +-
> contrib/fast-import/import-directories.perl | 2 +-
> contrib/hg-to-git/hg-to-git.py | 2 +-
> contrib/mw-to-git/t/test-gitmw-lib.sh | 4 ++--
> contrib/persistent-https/LICENSE | 2 +-
> contrib/persistent-https/README | 2 +-
> contrib/thunderbird-patch-inline/appp.sh | 2 +-
> contrib/update-unicode/update_unicode.sh | 6 +++---
> convert.c | 2 +-
> ewah/bitmap.c | 2 +-
> ewah/ewah_bitmap.c | 2 +-
> ewah/ewah_io.c | 2 +-
> ewah/ewah_rlw.c | 2 +-
> ewah/ewok.h | 4 ++--
> ewah/ewok_rlw.h | 2 +-
> xdiff/xdiff.h | 2 +-
> xdiff/xdiffi.c | 2 +-
> xdiff/xdiffi.h | 2 +-
> xdiff/xemit.c | 2 +-
> xdiff/xemit.h | 2 +-
> xdiff/xinclude.h | 2 +-
> xdiff/xmacros.h | 2 +-
> xdiff/xmerge.c | 2 +-
> xdiff/xpatience.c | 2 +-
> xdiff/xprepare.c | 2 +-
> xdiff/xprepare.h | 2 +-
> xdiff/xtypes.h | 2 +-
> xdiff/xutils.c | 2 +-
> xdiff/xutils.h | 2 +-
There are mostly borrowed code. I would not touch them, if I were
doing this patch (unless the HTTP:// variant stopped to work and
only HTTPS:// variant works now, that is).
Thanks.
| @@ -518,7 +518,7 @@ For Perl programs: | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/CodingGuidelines | 2 +-
> Documentation/RelNotes/1.6.2.txt | 2 +-
> Documentation/RelNotes/1.6.3.txt | 2 +-
> Documentation/RelNotes/1.6.4.txt | 2 +-
> Documentation/RelNotes/1.6.5.txt | 2 +-
> Documentation/RelNotes/1.6.6.txt | 2 +-
> Documentation/git-cvsimport.txt | 2 +-
> Documentation/git-format-patch.txt | 2 +-
> Documentation/git-ls-remote.txt | 4 ++--
> Documentation/git.txt | 2 +-
> Documentation/gitcore-tutorial.txt | 4 ++--
> compat/nedmalloc/malloc.c.h | 2 +-
> contrib/persistent-https/README | 2 +-
> git-gui/git-gui.sh | 2 +-
> gitk-git/gitk | 2 +-
> gitweb/static/js/lib/common-lib.js | 2 +-
> http.c | 2 +-
> imap-send.c | 2 +-
> json-writer.h | 2 +-
> 19 files changed, 21 insertions(+), 21 deletions(-)
Broken links are annoying while reading documentation. Thank you
for doing the necessary research.
I am not sure if direct replacement to Release Notes (historical
document) is the best way to present these updates, but let's assume
it is OK for now.
> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
> index 1c4f696ab57..b9c8478a62a 100644
> --- a/Documentation/git-ls-remote.txt
> +++ b/Documentation/git-ls-remote.txt
> @@ -128,7 +128,7 @@ d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
> * List all references matching given patterns:
> +
> ----
> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
> +$ git ls-remote https://git.kernel.org/pub/scm/git/git.git master seen rc
> 5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
> c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
> ----
I am not sure if this change is warranted. The old URL still works
just fine, even though there are no refs that match "rc" and the
"master" branch is no longer at 5fe978a5, but these are not problem
caused by using the http:// address. The point of the example is
not about preferred use of HTTP:// over HTTPS://, so this again
falls into "if we were writing this anew, we may have used the other
address, but the original still works, so it is not worth the patch
noise" category, I would think.
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> index 2122aeb9769..924a9a97807 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -1101,8 +1101,8 @@ Examples.
>
> the above are equivalent to:
>
> -. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
> -. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
> +. `git pull https://git.kernel.org/pub/scm/git/git.git/ HEAD`
> +. `git pull https://git.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
Likewise.
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index 11228956cd5..c7292eb25d0 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -1061,7 +1061,7 @@ Authors
> -------
> Git was started by Linus Torvalds, and is currently maintained by Junio
> C Hamano. Numerous contributions have come from the Git mailing list
> -<git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary
> +<git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary
> gives you a more complete list of contributors.
OK, even though the former seems to redirect to the latter, so in
that sense it is still "current".
> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> index 5c5357a379f..4b711c6b9ca 100644
> --- a/compat/nedmalloc/malloc.c.h
> +++ b/compat/nedmalloc/malloc.c.h
> @@ -1359,7 +1359,7 @@ LONG __cdecl _InterlockedExchange(LONG volatile *Target, LONG Value);
> /* --[ start GCC compatibility ]----------------------------------------------
> * Compatibility <intrin_x86.h> header for GCC -- GCC equivalents of intrinsic
> * Microsoft Visual C++ functions. Originally developed for the ReactOS
> - * (<http://www.reactos.org/>) and TinyKrnl (<http://www.tinykrnl.org/>)
> + * (<https://reactos.org/>) and TinyKrnl (<http://www.tinykrnl.org/>)
Likewise for reactos; the tinykrnl one does not seem to be current.
In any case, this is borrowed code, so I'd rather not touch it and
risk giving a wrong page that is not a replacement.
> diff --git a/contrib/persistent-https/README b/contrib/persistent-https/README
> index 2ad95893c27..2c9bec91066 100644
> --- a/contrib/persistent-https/README
> +++ b/contrib/persistent-https/README
> @@ -60,7 +60,7 @@ https://kernel.googlesource.com/pub/scm/git/git
>
> PREREQUISITES
>
> -The code is written in Go (http://golang.org/) and the Go compiler is
> +The code is written in Go (https://go.dev/) and the Go compiler is
Likewise.
> required. Currently, the compiler must be built and installed from tip
> of source, in order to include a fix in the reverse http proxy:
> https://code.google.com/p/go/source/detail?r=a615b796570a2cd8591884767a7d67ede74f6648
This is an interesting one. code.google.com is no longer tehre
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 1d6102e0674..4a11d590b68 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -2390,7 +2390,7 @@ proc do_quit {{rc {1}}} {
> set ret_code $rc
>
> # Briefly enable send again, working around Tk bug
> - # http://sourceforge.net/tracker/?func=detail&atid=112997&aid=1821174&group_id=12997
> + # https://sourceforge.net/p/tktoolkit/bugs/2343/
> tk appname [appname]
>
> destroy .
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 1db46977df0..7a087f123d7 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -12472,7 +12472,7 @@ if {[tk windowingsystem] eq "aqua"} {
>
> catch {
> # follow the XDG base directory specification by default. See
> - # http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> + # https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> if {[info exists env(XDG_CONFIG_HOME)] && $env(XDG_CONFIG_HOME) ne ""} {
> # XDG_CONFIG_HOME environment variable is set
> set config_file [file join $env(XDG_CONFIG_HOME) git gitk]
> diff --git a/gitweb/static/js/lib/common-lib.js b/gitweb/static/js/lib/common-lib.js
> index 17b1796496d..99e3eb8c3d9 100644
> --- a/gitweb/static/js/lib/common-lib.js
> +++ b/gitweb/static/js/lib/common-lib.js
> @@ -137,7 +137,7 @@ function addCssRule(selector, style) {
> * http://www.dustindiaz.com/getelementsbyclass/
> * https://stackoverflow.com/questions/1818865/do-we-have-getelementsbyclassname-in-javascript
> *
> - * See also http://ejohn.org/blog/getelementsbyclassname-speed-comparison/
> + * See also https://johnresig.com/blog/getelementsbyclassname-speed-comparison/
> *
> * @param {String} class: name of _single_ class to find
> * @param {String} [taghint] limit search to given tags
> diff --git a/http.c b/http.c
> index e138b4b96fb..33c6011e8d8 100644
> --- a/http.c
> +++ b/http.c
> @@ -1877,7 +1877,7 @@ static void write_accept_language(struct strbuf *buf)
> * MAX_DECIMAL_PLACES must not be larger than 3. If it is larger than
> * that, q-value will be smaller than 0.001, the minimum q-value the
> * HTTP specification allows. See
> - * http://tools.ietf.org/html/rfc7231#section-5.3.1 for q-value.
> + * https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.1 for q-value.
> */
> const int MAX_DECIMAL_PLACES = 3;
> const int MAX_LANGUAGE_TAGS = 1000;
> diff --git a/imap-send.c b/imap-send.c
> index 3b2077e39b2..448ca64c052 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -860,7 +860,7 @@ static void imap_close_store(struct imap_store *ctx)
>
> /*
> * hexchar() and cram() functions are based on the code from the isync
> - * project (http://isync.sf.net/).
> + * project (https://isync.sourceforge.io/).
> */
> static char hexchar(unsigned int b)
> {
> diff --git a/json-writer.h b/json-writer.h
> index de140e54c98..04413bd1afd 100644
> --- a/json-writer.h
> +++ b/json-writer.h
> @@ -4,7 +4,7 @@
> /*
> * JSON data structures are defined at:
> * [1] https://www.ietf.org/rfc/rfc7159.txt
> - * [2] http://json.org/
> + * [2] https://www.json.org/
> *
> * The JSON-writer API allows one to build JSON data structures using a
> * simple wrapper around a "struct strbuf" buffer. It is intended as a
| @@ -518,7 +518,7 @@ For Perl programs: | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/CodingGuidelines | 2 +-
> Documentation/RelNotes/1.6.2.txt | 2 +-
> Documentation/RelNotes/1.6.3.txt | 2 +-
> Documentation/RelNotes/1.6.4.txt | 2 +-
> Documentation/RelNotes/1.6.5.txt | 2 +-
> Documentation/RelNotes/1.6.6.txt | 2 +-
> Documentation/git-cvsimport.txt | 2 +-
> Documentation/git-format-patch.txt | 2 +-
> Documentation/git-ls-remote.txt | 4 ++--
> Documentation/git.txt | 2 +-
> Documentation/gitcore-tutorial.txt | 4 ++--
> compat/nedmalloc/malloc.c.h | 2 +-
> contrib/persistent-https/README | 2 +-
> git-gui/git-gui.sh | 2 +-
> gitk-git/gitk | 2 +-
> gitweb/static/js/lib/common-lib.js | 2 +-
> http.c | 2 +-
> imap-send.c | 2 +-
> json-writer.h | 2 +-
> 19 files changed, 21 insertions(+), 21 deletions(-)
Broken links are annoying while reading documentation. Thank you
for doing the necessary research.
I am not sure if direct replacement to Release Notes (historical
document) is the best way to present these updates, but let's assume
it is OK for now.
> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
> index 1c4f696ab57..b9c8478a62a 100644
> --- a/Documentation/git-ls-remote.txt
> +++ b/Documentation/git-ls-remote.txt
> @@ -128,7 +128,7 @@ d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
> * List all references matching given patterns:
> +
> ----
> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
> +$ git ls-remote https://git.kernel.org/pub/scm/git/git.git master seen rc
> 5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
> c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
> ----
I am not sure if this change is warranted. The old URL still works
just fine, even though there are no refs that match "rc" and the
"master" branch is no longer at 5fe978a5, but these are not problem
caused by using the http:// address. The point of the example is
not about preferred use of HTTP:// over HTTPS://, so this again
falls into "if we were writing this anew, we may have used the other
address, but the original still works, so it is not worth the patch
noise" category, I would think.
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> index 2122aeb9769..924a9a97807 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -1101,8 +1101,8 @@ Examples.
>
> the above are equivalent to:
>
> -. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
> -. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
> +. `git pull https://git.kernel.org/pub/scm/git/git.git/ HEAD`
> +. `git pull https://git.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
Likewise.
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index 11228956cd5..c7292eb25d0 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -1061,7 +1061,7 @@ Authors
> -------
> Git was started by Linus Torvalds, and is currently maintained by Junio
> C Hamano. Numerous contributions have come from the Git mailing list
> -<git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary
> +<git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary
> gives you a more complete list of contributors.
OK, even though the former seems to redirect to the latter, so in
that sense it is still "current".
> diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
> index 5c5357a379f..4b711c6b9ca 100644
> --- a/compat/nedmalloc/malloc.c.h
> +++ b/compat/nedmalloc/malloc.c.h
> @@ -1359,7 +1359,7 @@ LONG __cdecl _InterlockedExchange(LONG volatile *Target, LONG Value);
> /* --[ start GCC compatibility ]----------------------------------------------
> * Compatibility <intrin_x86.h> header for GCC -- GCC equivalents of intrinsic
> * Microsoft Visual C++ functions. Originally developed for the ReactOS
> - * (<http://www.reactos.org/>) and TinyKrnl (<http://www.tinykrnl.org/>)
> + * (<https://reactos.org/>) and TinyKrnl (<http://www.tinykrnl.org/>)
Likewise for reactos; the tinykrnl one does not seem to be current.
In any case, this is borrowed code, so I'd rather not touch it and
risk giving a wrong page that is not a replacement.
> diff --git a/contrib/persistent-https/README b/contrib/persistent-https/README
> index 2ad95893c27..2c9bec91066 100644
> --- a/contrib/persistent-https/README
> +++ b/contrib/persistent-https/README
> @@ -60,7 +60,7 @@ https://kernel.googlesource.com/pub/scm/git/git
>
> PREREQUISITES
>
> -The code is written in Go (http://golang.org/) and the Go compiler is
> +The code is written in Go (https://go.dev/) and the Go compiler is
Likewise.
> required. Currently, the compiler must be built and installed from tip
> of source, in order to include a fix in the reverse http proxy:
> https://code.google.com/p/go/source/detail?r=a615b796570a2cd8591884767a7d67ede74f6648
This is an interesting one. code.google.com is no longer there and
the updated URL seems to be at https://github.com/golang/go somewhere.
|
/submit |
|
Submitted as pull.1589.v2.git.1695553041.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): "Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> There are a couple of categories of http links
The same comment applies to the previous round, but it is not clear
how the categories of links that are HTTP in the current code (the
first enumeration) are related to how HTTP links are modified in the
series (the second enumeration). It is not like how the first one
in the first list (i.e. must be HTTP) is handled is described by the
first one in the second list (i.e. replace HTTP to HTTPS without
doing anything else), as the number of bullet points are different.
> * links that are required to be http: because they're copied from something
> that mandates it (the apache license, xml namespaces, xsl docbook
> things?)
So these are in "must stay as-is" category?
> * pages which exist at both http: and https: and can be safely switched
"Can be switched" does not mean we should switch, does it?
> * pages that have jittered a bit but are now available as https:
... but not available over HTTP:? If so, this falls into "must
switch to avoid a dangling link" category?
> * pages that have jittered a bit and are not available over https:
Again, "must stay as-is"?
> * pages that are gone and for which the best source is
> https://web.archive.org
Unfortunate, but definitely improves things.
> * urls that were imaginary
What is done to them? Just leave them as they are, or replace with
another imaginary link over HTTPS?
Hopefully we will see in the proposed commit log message of
individual patches what kind of http:// links the patch deals with
and how (e.g. "For some URLs in the documentation and the code, the
original http:// links are not reachable and dangling but the same
contents are still available at https://; for these URLs, replace
http:// with https:// without doing anything else."). Let's read
on.
> In order:
>
> * doc: switch links to https -- the simplest
> * doc: update links to current pages -- I found the current pages for
> these, it should be easy enough to verify these / reject them
> * doc: update links for andre-simon.de -- I've split this out, I don't like
> the idea of having to download binaries over http. If this were my
> project, I'd be tempted to remove the feature or self-host w/ https...
> * doc: refer to internet archive -- the original urls are dead, I've found
> internet archive date links for them. (There are some in git already, so
> this seemed like a very reasonable choice.)
> cc: Eric Sunshine sunshine@sunshineco.com cc: Josh Soref jsoref@gmail.com
(administrivia) I am not sure what effect, if any, this line has. |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): On Mon, Sep 25, 2023 at 2:35 PM Junio C Hamano <gitster@pobox.com> wrote:
> "Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > cc: Eric Sunshine sunshine@sunshineco.com cc: Josh Soref jsoref@gmail.com
>
> (administrivia) I am not sure what effect, if any, this line has.
GitGitGadget specially recognizes Cc: trailers in the pull-request's
description[1] to ensure that the named individuals receive a copy of
the emailed patch series, so this is a good way to Cc: people who
commented upon previous versions of the series. Unfortunately, in this
case, it appears that GitGitGadget ignored the two "cc:" lines because
they weren't proper trailers; there are additional non-trailer lines
following them in the pull-request's description (and they were taken
as just more Markdown body content).
[1]: https://github.com/gitgitgadget/git/pull/1589#issue-1908988061 |
|
User |
|
This branch is now known as |
|
This patch series was integrated into seen via git@d8d3a12. |
|
This patch series was integrated into seen via git@aaa926e. |
|
There was a status update in the "New Topics" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Needs eyeballing. source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@5ae0dfc. |
|
This patch series was integrated into seen via git@ac1f8ff. |
|
This patch series was integrated into seen via git@e00c5ae. |
|
This patch series was integrated into seen via git@68b575f. |
|
There was a status update in the "Cooking" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Needs eyeballing. source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@c1cda14. |
|
This patch series was integrated into seen via git@2cc1514. |
|
There was a status update in the "Cooking" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Needs eyeballing. source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@4cf8c3f. |
|
There was a status update in the "Cooking" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Needs review. source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com> |
These sites offer https versions of their content. Using the https versions provides some protection for users. Signed-off-by: Josh Soref <jsoref@gmail.com>
Beyond the fact that it's somewhat traditional to respect sites' self-identification, it's helpful for links to point to the things that people expect them to reference. Here that means linking to specific pages instead of a domain. Signed-off-by: Josh Soref <jsoref@gmail.com>
These pages are no longer reachable from their original locations, which makes things difficult for readers. Instead, switch to linking to the Internet Archive for the content. Signed-off-by: Josh Soref <jsoref@gmail.com>
|
/submit |
|
Submitted as pull.1589.v3.git.1700796916.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Elijah Newren wrote (reply to this): On Thu, Nov 23, 2023 at 7:35 PM Josh Soref via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> There are a couple of categories of http links...
>
> There are four categories worth changing:
>
> * pages that have jittered a bit but are now available as https:
> * pages which exist at both http: and https: and can be safely switched
> * pages that have jittered a bit and are not available over https:
> * pages that are gone and for which the best source is
> https://web.archive.org
>
> And some categories that aren't being changed:
>
> * links that are required to be http: because they're copied from something
> that mandates it (the apache license, xml namespaces, xsl docbook
> things?)
> * urls that were imaginary (e.g. http://example.com/repo.git)
> * links in borrowed code where the http: form still works
>
> In order:
>
> * doc: update links to current pages -- I found the current pages for
> these, it should be easy enough to verify these / reject them
> * doc: switch links to https -- the simplest
> * doc: update links for andre-simon.de -- I've split this out, I don't like
> the idea of having to download binaries over http. If this were my
> project, I'd be tempted to remove the feature or self-host w/ https...
> * doc: refer to internet archive -- the original urls are dead, I've found
> internet archive date links for them. (There are some in git already, so
> this seemed like a very reasonable choice.)
>
> Changes from v1:
>
> * Commit messages have been adjusted since v1
> * files were dropped based on feedback from Junio
>
> Changes from v2:
>
> * The first two commits have been swapped (favoring more complicated urls
> over simply switching to https)
> * The archive.org link for atomenabled.org has been dropped, we'll risk
> users getting hacked content from an arbitrary MITM instead of taking
> archived authenticated content based on the last time their web site was
> properly maintained.
As stated elsewhere, I'd be fine with using the archived link if the
justification presented in the series for using archived links was
consistent and mentioned both reasons for changes. But, I think this
series is fine to merge down as-is if you don't want to go through the
trouble. Especially given how long you've waited.
Anyway, I checked through every link in this series; it all looks good to me. |
|
On the Git mailing list, Josh Soref wrote (reply to this): Elijah Newren wrote:
> As stated elsewhere, I'd be fine with using the archived link if the
> justification presented in the series for using archived links was
> consistent and mentioned both reasons for changes. But, I think this
> series is fine to merge down as-is if you don't want to go through the
> trouble. Especially given how long you've waited.
I'm clearly still contributing, so I can come back later and cross
that bridge...
> Anyway, I checked through every link in this series; it all looks good to me.
Let's take this as-is. Thanks for taking the time to re-check every
link, I know exactly how tedious that is :). |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): Josh Soref <jsoref@gmail.com> writes:
> Elijah Newren wrote:
>> As stated elsewhere, I'd be fine with using the archived link if the
>> justification presented in the series for using archived links was
>> consistent and mentioned both reasons for changes. But, I think this
>> series is fine to merge down as-is if you don't want to go through the
>> trouble. Especially given how long you've waited.
>
> I'm clearly still contributing, so I can come back later and cross
> that bridge...
>
>> Anyway, I checked through every link in this series; it all looks good to me.
>
> Let's take this as-is. Thanks for taking the time to re-check every
> link, I know exactly how tedious that is :).
Thanks, both. Will queue.
|
|
There was a status update in the "Cooking" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Will merge to 'next'. source: <pull.1589.v3.git.1700796916.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@fcb056f. |
|
This patch series was integrated into seen via git@e7d90bd. |
|
There was a status update in the "Cooking" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Will merge to 'next'. source: <pull.1589.v3.git.1700796916.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@9f7001d. |
|
This patch series was integrated into next via git@d05ea60. |
|
This patch series was integrated into next via git@3cda3f2. |
|
This patch series was integrated into seen via git@43fd3e3. |
|
There was a status update in the "Cooking" section about the branch Stale URLs have been updated to their current counterparts (or archive.org) and HTTP links are replaced with working HTTPS links. Will merge to 'master'. source: <pull.1589.v3.git.1700796916.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@42be210. |
|
This patch series was integrated into seen via git@2fd1424. |
|
This patch series was integrated into seen via git@b557359. |
|
This patch series was integrated into seen via git@8451ea9. |
|
This patch series was integrated into seen via git@ec5ab14. |
|
This patch series was integrated into master via git@ec5ab14. |
|
This patch series was integrated into next via git@ec5ab14. |
|
Closed via ec5ab14. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are a couple of categories of
httplinks...There are four categories worth changing:
https:http:andhttps:and can be safely switchedhttps:https://web.archive.orgAnd some categories that aren't being changed:
http://example.com/repo.git)http:form still worksIn order:
doc: update links to current pages-- I found the current pages for these, it should be easy enough to verify these / reject themdoc: switch links to https-- the simplestdoc: update links for andre-simon.de-- I've split this out, I don't like the idea of having to download binaries over http. If this were my project, I'd be tempted to remove the feature or self-host w/ https...doc: refer to internet archive-- the original urls are dead, I've found internet archive date links for them. (There are some in git already, so this seemed like a very reasonable choice.)Changes from v1:
Changes from v2:
https)cc: Eric Sunshine sunshine@sunshineco.com
cc: Josh Soref jsoref@gmail.com
cc: Elijah Newren newren@gmail.com