From: Konstantin Ryabitsev <hidden> Date: 2019-11-20 15:43:53
Hi, all:
I used Eric's public-inbox.org archives to set up our own copy on
lore.kernel.org and identical list archives are now available on that
server.
I spoke with Eric and he recommends that official project documentation
starts using lore.kernel.org/git URLs in daily use and git's official
documentation in order to allow him more freedom of decision when it
comes to hosting his equipment. The URLs at both domains remain the
same, e.g.:
- https://public-inbox.org/git/7vll0wvb2a.fsf@assigned-by-dhcp.cox.net/
- https://lore.kernel.org/git/7vll0wvb2a.fsf@assigned-by-dhcp.cox.net/
Best regards,
-K
From: Eric Wong <hidden> Date: 2019-11-20 19:55:58
Konstantin Ryabitsev [off-list ref] wrote:
Hi, all:
I used Eric's public-inbox.org archives to set up our own copy on
lore.kernel.org and identical list archives are now available on that
server.
I spoke with Eric and he recommends that official project documentation
starts using lore.kernel.org/git URLs in daily use and git's official
documentation in order to allow him more freedom of decision when it
comes to hosting his equipment. The URLs at both domains remain the
same, e.g.:
Yup, .org TLD renewal costs will likely go up and I won't pay
higher costs to keep .org domains.
The system running public-inbox.org (and the recommended
onions(*)) will stay running and will have bleeding edge
code on it.
* Accessible via Tor, no need to depend on registrars:
http://hjrcffqmbrq6wope.onion/http://ou63pmih66umazou.onion/http://czquwvybam4bgbro.onion/
From: Jeff King <hidden> Date: 2019-11-27 12:52:33
On Wed, Nov 20, 2019 at 10:43:47AM -0500, Konstantin Ryabitsev wrote:
I used Eric's public-inbox.org archives to set up our own copy on
lore.kernel.org and identical list archives are now available on that
server.
I spoke with Eric and he recommends that official project documentation
starts using lore.kernel.org/git URLs in daily use and git's official
documentation in order to allow him more freedom of decision when it
comes to hosting his equipment. The URLs at both domains remain the
same, e.g.:
- https://public-inbox.org/git/7vll0wvb2a.fsf@assigned-by-dhcp.cox.net/
- https://lore.kernel.org/git/7vll0wvb2a.fsf@assigned-by-dhcp.cox.net/
Thank you for setting this up (and thank you Eric for the public-inbox
code and service; it's _so_ much nicer than the previous alternatives).
It sounds like we should do something like the series below.
[1/2]: doc: recommend lore.kernel.org over public-inbox.org
[2/2]: doc: replace public-inbox links with lore.kernel.org
Documentation/MyFirstContribution.txt | 2 +-
Documentation/git-bisect-lk2009.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/technical/commit-graph.txt | 10 +++++-----
.../technical/hash-function-transition.txt | 14 +++++++-------
Documentation/technical/multi-pack-index.txt | 4 ++--
Documentation/technical/partial-clone.txt | 12 ++++++------
README.md | 2 +-
apply.c | 2 +-
sha1dc/sha1.c | 2 +-
t/t0021-conversion.sh | 4 ++--
t/t4038-diff-combined.sh | 2 +-
tree-walk.c | 2 +-
13 files changed, 30 insertions(+), 30 deletions(-)
-Peff
From: Jeff King <hidden> Date: 2019-11-27 12:53:46
Since lore.kernel.org now has the same archive as public-inbox.org and
may have more longevity going forward[1], let's recommend people use it
for finding or referencing messages.
[1] https://public-inbox.org/git/20191120195556.GA25189@dcvr/
or if you like:
https://lore.kernel.org/git/20191120195556.GA25189@dcvr/
Signed-off-by: Jeff King <redacted>
---
And it's one character shorter. Think of all of the bytes saved!
Documentation/MyFirstContribution.txt | 2 +-
Documentation/git.txt | 2 +-
README.md | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
@@ -970,7 +970,7 @@ reviewers the changes you've made that may not be as visible. You will also need to go and find the Message-Id of your previous cover letter. You can either note it when you send the first series, from the output of `git send-email`, or you can look it up on the-https://public-inbox.org/git[mailing list]. Find your cover letter in the+https://lore.kernel.org/git[mailing list]. Find your cover letter in the archives, click on it, then click "permalink" or "raw" to reveal the Message-Id header. It should match:
@@ -928,7 +928,7 @@ Reporting Bugs Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be subscribed to the list to send a message there. See the list archive-at https://public-inbox.org/git for previous bug reports and other+at https://lore.kernel.org/git for previous bug reports and other discussions. Issues which are security relevant should be disclosed privately to
@@ -35,7 +35,7 @@ requests, comments and patches to git@vger.kernel.org (read [Documentation/SubmittingPatches][] for instructions on patch submission). To subscribe to the list, send an email with just "subscribe git" in the body to majordomo@vger.kernel.org. The mailing list archives are-available at <https://public-inbox.org/git/>,+available at <https://lore.kernel.org/git/>, <http://marc.info/?l=git> and other archival sites. Issues which are security relevant should be disclosed privately to
@@ -323,14 +323,14 @@ Related Links [0] https://bugs.chromium.org/p/git/issues/detail?id=8 Chromium work item for: Serialized Commit Graph-[1] https://public-inbox.org/git/20110713070517.GC18566@sigill.intra.peff.net/+[1] https://lore.kernel.org/git/20110713070517.GC18566@sigill.intra.peff.net/ An abandoned patch that introduced generation numbers.-[2] https://public-inbox.org/git/20170908033403.q7e6dj7benasrjes@sigill.intra.peff.net/+[2] https://lore.kernel.org/git/20170908033403.q7e6dj7benasrjes@sigill.intra.peff.net/ Discussion about generation numbers on commits and how they interact with fsck.-[3] https://public-inbox.org/git/20170908034739.4op3w4f2ma5s65ku@sigill.intra.peff.net/+[3] https://lore.kernel.org/git/20170908034739.4op3w4f2ma5s65ku@sigill.intra.peff.net/ More discussion about generation numbers and not storing them inside commit objects. A valuable quote:
@@ -342,9 +342,9 @@ Related Links commit objects (i.e., packv4 or something like the "metapacks" I proposed a few years ago)."-[4] https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u+[4] https://lore.kernel.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u A patch to remove the ahead-behind calculation from 'status'.-[5] https://public-inbox.org/git/f27db281-abad-5043-6d71-cbb083b1c877@gmail.com/+[5] https://lore.kernel.org/git/f27db281-abad-5043-6d71-cbb083b1c877@gmail.com/ A discussion of a "two-dimensional graph position" that can allow reading multiple commit-graph chains at the same time.
@@ -730,7 +730,7 @@ adoption. Using hash functions in parallel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-(e.g. https://public-inbox.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/ )+(e.g. https://lore.kernel.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/ ) Objects newly created would be addressed by the new hash, but inside such an object (e.g. commit) it is still possible to address objects using the old hash function.
@@ -783,7 +783,7 @@ bmwill@google.com, jonathantanmy@google.com, jrnieder@gmail.com, sbeller@google.com Initial version sent to-http://public-inbox.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com+http://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com 2017-03-03 jrnieder@gmail.com Incorporated suggestions from jonathantanmy and sbeller:
@@ -820,8 +820,8 @@ Later history: edits. This document history is no longer being maintained as it would now be superfluous to the commit log-[1] http://public-inbox.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/-[2] http://public-inbox.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/-[3] http://public-inbox.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/-[4] http://public-inbox.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net-[5] https://public-inbox.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/+[1] http://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/+[2] http://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/+[3] http://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/+[4] http://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net+[5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/
@@ -35,7 +35,7 @@ filter_git () {# Compare two files and ensure that `clean` and `smudge` respectively are# called at least once if specified in the `expect` file. The actual# invocation count is not relevant because their number can vary.-# c.f. http://public-inbox.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/+# c.f. http://lore.kernel.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/ test_cmp_count(){expect=$1actual=$2
@@ -50,7 +50,7 @@ test_cmp_count () {# Compare two files but exclude all `clean` invocations because Git can# call `clean` zero or more times.-# c.f. http://public-inbox.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/+# c.f. http://lore.kernel.org/git/xmqqshv18i8i.fsf@gitster.mtv.corp.google.com/ test_cmp_exclude_clean(){expect=$1actual=$2
@@ -354,7 +354,7 @@ test_expect_failure 'combine diff coalesce three parents' ''# Test for a bug reported at-# https://public-inbox.org/git/20130515143508.GO25742@login.drsnuggles.stderr.nl/+# https://lore.kernel.org/git/20130515143508.GO25742@login.drsnuggles.stderr.nl/# where a delete lines were missing from combined diff output when they# occurred exactly before the context lines of a later change. test_expect_success'combine diff missing delete bug''
:> URL length has always bothered me.
peff.net/git/$MESSAGE_ID/ would be nice to have, as well :)
Anyways, consider this series:
Acked-by: Eric Wong <redacted>
(and I doubt I'll keep paying for 80x24.org, either...)
Since we're now recommending lore.kernel.org (and because the
public-inbox.org domain might eventually go away), let's update our
internal references to use it, too. That future-proofs our references,
and sets the example we want people to follow.
This is a great idea. I clicked a few of the links to verify they
work.
-Stolee
Hi, all:
I used Eric's public-inbox.org archives to set up our own copy on
lore.kernel.org and identical list archives are now available on that
server.
I spoke with Eric and he recommends that official project documentation
starts using lore.kernel.org/git URLs in daily use and git's official
documentation in order to allow him more freedom of decision when it
comes to hosting his equipment. The URLs at both domains remain the
same, e.g.:
Yup, .org TLD renewal costs will likely go up and I won't pay
higher costs to keep .org domains.
The system running public-inbox.org (and the recommended
onions(*)) will stay running and will have bleeding edge
code on it.
* Accessible via Tor, no need to depend on registrars:
http://hjrcffqmbrq6wope.onion/http://ou63pmih66umazou.onion/http://czquwvybam4bgbro.onion/
I think it would make sense for the Git SFC arm of things[1] to consider
taking over the public-inbox.org domain rather than letting it expire
(of course contingent on your approval) and turning it into a CNAME (or
other redirect) for lore.kernel.org.
We have a lot of mailing list and some (~130 commits) git.git commit
references to that domain. It seems like a worthwhile expense to me to
pay for the renewal of it rather than having it turn into e.g. some spam
landing page as the registration expires.
1. Disclaimer: I'm one of the people who'd vote on making that decision
if it came to that, but this E-Mail is, as they say, just like, my
opinion, man :)
From: Jeff King <hidden> Date: 2019-11-27 16:18:39
On Wed, Nov 27, 2019 at 04:31:51PM +0100, Ævar Arnfjörð Bjarmason wrote:
I think it would make sense for the Git SFC arm of things[1] to consider
taking over the public-inbox.org domain rather than letting it expire
(of course contingent on your approval) and turning it into a CNAME (or
other redirect) for lore.kernel.org.
We have a lot of mailing list and some (~130 commits) git.git commit
references to that domain. It seems like a worthwhile expense to me to
pay for the renewal of it rather than having it turn into e.g. some spam
landing page as the registration expires.
1. Disclaimer: I'm one of the people who'd vote on making that decision
if it came to that, but this E-Mail is, as they say, just like, my
opinion, man :)
I'm also one of those people, and I'd consider it as well. A lot of it
would depend on the cost, and what happens with this whole .org
registrar thing.
-Peff
From: Denton Liu <hidden> Date: 2019-11-27 19:28:57
Thanks for doing this. Perhaps while we're at it, we want to change all
of the MARC and Gmane links as well? The series below does this.
I've based my series on top of yours so if you need to do a reroll, feel
free to pick my changes in.
Denton Liu (2):
doc: replace MARC links with LKML
RelNotes: replace Gmane with real Message-IDs
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/RelNotes/1.8.4.txt | 2 +-
Documentation/RelNotes/2.5.0.txt | 3 ++-
Documentation/RelNotes/2.8.3.txt | 4 ++--
Documentation/RelNotes/2.9.0.txt | 2 +-
Documentation/git-bisect-lk2009.txt | 2 +-
Documentation/gitcli.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
t/t6021-merge-criss-cross.sh | 2 +-
13 files changed, 17 insertions(+), 16 deletions(-)
--
2.24.0.504.g3cd56eb17d
From: Denton Liu <hidden> Date: 2019-11-27 19:29:00
Since we're now recommending lore.kernel.org, replace marc.info links
with lore.kernel.org.
Although MARC has been around for a long time, nothing lasts forever
(see Gmane). Since MARC uses opaque message identifiers, switching to
LKML should be a strict improvement since, even if LKML goes
down, the Message-ID will allow future readers to look up the referenced
messages on any other archive.
We leave behind one reference to MARC in the README.md since it's a
perfectly fine mail archive for personal reading, just not for linking
messages for the future.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-bisect-lk2009.txt | 2 +-
Documentation/gitcli.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
t/t6021-merge-criss-cross.sh | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
@@ -211,8 +211,8 @@ only affects the files in the working tree, but with entries, and with `--cached`, it modifies only the index entries.-See also http://marc.info/?l=git&m=116563135620359 and-http://marc.info/?l=git&m=119150393620273 for further+See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and+https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ for further information. Some other commands that also work on files in the working tree and/or
@@ -4574,5 +4574,5 @@ Write a chapter on using plumbing and writing scripts. Alternates, clone -reference, etc. More on recovery from repository corruption. See:- http://marc.info/?l=git&m=117263864820799&w=2- http://marc.info/?l=git&m=117147855503798&w=2+ https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/+ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/
@@ -3,7 +3,7 @@# Copyright (c) 2005 Fredrik Kuivinen#-# See http://marc.info/?l=git&m=111463358500362&w=2 for a+# See https://lore.kernel.org/git/Pine.LNX.4.44.0504271254120.4678-100000@wax.eds.org/ for a# nice description of what this is about.
From: Denton Liu <hidden> Date: 2019-11-27 19:29:02
The only references to Gmane that remain are in RelNotes. Although these
are definitely not in active use, they might be of historical interest
for future readers so let's ensure that mail references are more robust.
Replace links to Gmane with links to LKML (which is our new preferred
mailing list archive and has the Message-ID in the URL) and bare Gmane
ID references with Message-IDs.
The Message-IDs were found by searching for "gmane:<id>" on
https://public-inbox.org/git/ and taking the resulting message.
Signed-off-by: Denton Liu <redacted>
---
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/RelNotes/1.8.4.txt | 2 +-
Documentation/RelNotes/2.5.0.txt | 3 ++-
Documentation/RelNotes/2.8.3.txt | 4 ++--
Documentation/RelNotes/2.9.0.txt | 2 +-
9 files changed, 11 insertions(+), 10 deletions(-)
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -22,7 +22,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -64,7 +64,7 @@ users will fare this time. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition process that already took place so far.
@@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports. credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that- this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it+ this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has
@@ -172,7 +172,8 @@ Performance, Internal Implementation, Development Support etc. incorrect patch text to "git apply". Add tests to demonstrate this.- I have a slight suspicion that this may be $gmane/87202 coming back+ I have a slight suspicion that this may be+ cf. <7vtzf77wjp.fsf@gitster.siamese.dyndns.org> coming back and biting us (I seem to have said "let's run with this and see what happens" back then).
@@ -55,8 +55,8 @@ Fixes since v2.8.2 This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while.- See http://thread.gmane.org/gmane.comp.version-control.git/291853- and http://thread.gmane.org/gmane.comp.version-control.git/275680.+ See https://lkml.org/git/20160419091055.GF2345@dinwoodie.org/+ and https://lkml.org/git/20150811100527.GW14466@dinwoodie.org/. * "git replace -e" did not honour "core.editor" configuration.
@@ -368,7 +368,7 @@ notes for details). This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while.- See http://thread.gmane.org/gmane.comp.version-control.git/291853+ See https://lkml.org/git/20160419091055.GF2345@dinwoodie.org/ * "merge-octopus" strategy did not ensure that the index is clean when merge begins.
One of the things I appreciate most about https://public-inbox.org/git is
that you can clone it. I just tried this with
https://lore.kernel.org/git/...
$ git clone https://lore.kernel.org/git/ lore-git
Cloning into 'lore-git'...
warning: You appear to have cloned an empty repository.
Is this something other people also care about?
Ciao,
Dscho
quoted
Signed-off-by: Jeff King <redacted>
---
And it's one character shorter. Think of all of the bytes saved!
:> URL length has always bothered me.
peff.net/git/$MESSAGE_ID/ would be nice to have, as well :)
Anyways, consider this series:
Acked-by: Eric Wong <redacted>
(and I doubt I'll keep paying for 80x24.org, either...)
Oops, that's a usability issue I hope to fix at some point.
Is this something other people also care about?
Instructions are actually at the bottom:
git clone --mirror https://lore.kernel.org/git/0 git/git/0.git
The "0" is the "epoch", and larger repos have multiple epochs,
roughly 1GB each. https://lore.kernel.org/lkml/ has 0..7, right now.
From: Eric Wong <hidden> Date: 2019-11-27 20:25:33
Ævar Arnfjörð Bjarmason [off-list ref] wrote:
On Wed, Nov 20 2019, Eric Wong wrote:
quoted
Yup, .org TLD renewal costs will likely go up and I won't pay
higher costs to keep .org domains.
The system running public-inbox.org (and the recommended
onions(*)) will stay running and will have bleeding edge
code on it.
* Accessible via Tor, no need to depend on registrars:
http://hjrcffqmbrq6wope.onion/http://ou63pmih66umazou.onion/http://czquwvybam4bgbro.onion/
I think it would make sense for the Git SFC arm of things[1] to consider
taking over the public-inbox.org domain rather than letting it expire
(of course contingent on your approval) and turning it into a CNAME (or
other redirect) for lore.kernel.org.
We have a lot of mailing list and some (~130 commits) git.git commit
references to that domain. It seems like a worthwhile expense to me to
pay for the renewal of it rather than having it turn into e.g. some spam
landing page as the registration expires.
One feature I'd like to see in public-inbox and even git
porcelain and web viewers is the ability to rewrite URLs on the
client-side, similar to .mailmap. It would make sense they all
share the same configuration.
1. Disclaimer: I'm one of the people who'd vote on making that decision
if it came to that, but this E-Mail is, as they say, just like, my
opinion, man :)
Fwiw, I intentionally keep the branding of the public-inbox
project weak (no trademarks, logos, real homepage) because I
believe strong branding and consolidation of influence/identity
leads to centralization. It's easier to fork projects when
there's no logos, trademarks or other branding to deal with.
I also believe the term "public inbox" is a much more powerful
idea than any project could be. To that end, I'm happy
SourceHut (and maybe others) also use that term. The
"public-inbox" project is just one cheapskate's anti-consumerist
interpretation of that idea :>
I pretty much say whatever I can to sabotage my own credibility
as a result. I'm also shy and introverted, so branding and good
marketing does not compute :P
From: Denton Liu <hidden> Date: 2019-11-28 00:16:20
On Wed, Nov 27, 2019 at 11:28:57AM -0800, Denton Liu wrote:
The only references to Gmane that remain are in RelNotes. Although these
are definitely not in active use, they might be of historical interest
for future readers so let's ensure that mail references are more robust.
Replace links to Gmane with links to LKML (which is our new preferred
In this and the last patch, I had a brainfart and I thought LKML and
lore.kernel.org were the same thing but obviously they're not.
quoted hunk
mailing list archive and has the Message-ID in the URL) and bare Gmane
ID references with Message-IDs.
The Message-IDs were found by searching for "gmane:<id>" on
https://public-inbox.org/git/ and taking the resulting message.
Signed-off-by: Denton Liu <redacted>
---
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/RelNotes/1.8.4.txt | 2 +-
Documentation/RelNotes/2.5.0.txt | 3 ++-
Documentation/RelNotes/2.8.3.txt | 4 ++--
Documentation/RelNotes/2.9.0.txt | 2 +-
9 files changed, 11 insertions(+), 10 deletions(-)
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -22,7 +22,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -64,7 +64,7 @@ users will fare this time. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition process that already took place so far.
@@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports. credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that- this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it+ this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has
@@ -172,7 +172,8 @@ Performance, Internal Implementation, Development Support etc. incorrect patch text to "git apply". Add tests to demonstrate this.- I have a slight suspicion that this may be $gmane/87202 coming back+ I have a slight suspicion that this may be+ cf. <7vtzf77wjp.fsf@gitster.siamese.dyndns.org> coming back and biting us (I seem to have said "let's run with this and see what happens" back then).
@@ -55,8 +55,8 @@ Fixes since v2.8.2 This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while.- See http://thread.gmane.org/gmane.comp.version-control.git/291853- and http://thread.gmane.org/gmane.comp.version-control.git/275680.+ See https://lkml.org/git/20160419091055.GF2345@dinwoodie.org/+ and https://lkml.org/git/20150811100527.GW14466@dinwoodie.org/.
Brainfart continues here... Wrong URL.
quoted hunk
* "git replace -e" did not honour "core.editor" configuration.
@@ -368,7 +368,7 @@ notes for details). This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while.- See http://thread.gmane.org/gmane.comp.version-control.git/291853+ See https://lkml.org/git/20160419091055.GF2345@dinwoodie.org/
And here. If Peff's series gets picked up, I'll reroll mine as well.
* "merge-octopus" strategy did not ensure that the index is clean
when merge begins.
--
2.24.0.504.g3cd56eb17d
Oops, that's a usability issue I hope to fix at some point.
That would be nice. As you can tell from my puzzlement, not everybody
scrolls down to the instruction (which I finally found after your
comment)...
:-D
quoted
Is this something other people also care about?
Instructions are actually at the bottom:
git clone --mirror https://lore.kernel.org/git/0 git/git/0.git
The "0" is the "epoch", and larger repos have multiple epochs,
roughly 1GB each. https://lore.kernel.org/lkml/ has 0..7, right now.
Okay, so how does that work, is the idea that you should graft them
together using replacement objects if you want to have the full archive?
And: if I want to track the latest mails in GitGitGadget, what indication
will I have that I'll need to switch to `.../1`?
Thanks,
Dscho
From: Eric Wong <hidden> Date: 2019-11-28 19:48:31
Johannes Schindelin [off-list ref] wrote:
On Wed, 27 Nov 2019, Eric Wong wrote:
quoted
The "0" is the "epoch", and larger repos have multiple epochs,
roughly 1GB each. https://lore.kernel.org/lkml/ has 0..7, right now.
Okay, so how does that work, is the idea that you should graft them
together using replacement objects if you want to have the full archive?
Yes. Except we don't actually use grafts/replace and users can
currently only clone the latest epoch of LKML. In the future,
it should also be easy to jettison old epochs if space is
limited.
And: if I want to track the latest mails in GitGitGadget, what indication
will I have that I'll need to switch to `.../1`?
You can use the gzipped JSON grokmirror manifest at:
https://lore.kernel.org/git/manifest.js.gz
grokmirror could be a bit of a pain to install because of Python
dependencies, so periodically attempting to clone the next
numbered epoch ought to be fine, too.
I've also considered adding epoch info into
https://lore.kernel.org/git/_/text/config/raw
so shell scripters w/o JSON parsers can use "git config"
From: Johannes Schindelin <hidden> Date: 2019-11-28 22:17:40
Hi Eric,
On Thu, 28 Nov 2019, Eric Wong wrote:
Johannes Schindelin [off-list ref] wrote:
quoted
And: if I want to track the latest mails in GitGitGadget, what indication
will I have that I'll need to switch to `.../1`?
You can use the gzipped JSON grokmirror manifest at:
https://lore.kernel.org/git/manifest.js.gz
grokmirror could be a bit of a pain to install because of Python
dependencies, so periodically attempting to clone the next
numbered epoch ought to be fine, too.
I've also considered adding epoch info into
https://lore.kernel.org/git/_/text/config/raw
so shell scripters w/o JSON parsers can use "git config"
I just had a look at its contents:
-- snip --
; example public-inbox config snippet for "git"
; see public-inbox-config(5) manpage for more details:
; https://public-inbox.org/public-inbox-config.html
[publicinbox "git"]
inboxdir = /path/to/top-level-inbox
; note: public-inbox before v1.2.0 used "mainrepo"
; instead of "inboxdir", both remain supported after 1.2
mainrepo = /path/to/top-level-inbox
address = git@vger.kernel.org
listid = git.vger.kernel.org
filter = PublicInbox::Filter::Mirror
newsgroup = org.kernel.vger.git
nntpmirror = nntp://nntp.lore.kernel.org/org.kernel.vger.git
-- snap --
Isn't `inboxdir` and `mainrepo` incorrect?
And yes, adding `epoch` information there would be very welcome.
Thanks,
Dscho
From: Eric Wong <hidden> Date: 2019-11-28 22:31:47
Johannes Schindelin [off-list ref] wrote:
Hi Eric,
On Thu, 28 Nov 2019, Eric Wong wrote:
quoted
Johannes Schindelin [off-list ref] wrote:
quoted
And: if I want to track the latest mails in GitGitGadget, what indication
will I have that I'll need to switch to `.../1`?
You can use the gzipped JSON grokmirror manifest at:
https://lore.kernel.org/git/manifest.js.gz
grokmirror could be a bit of a pain to install because of Python
dependencies, so periodically attempting to clone the next
numbered epoch ought to be fine, too.
I've also considered adding epoch info into
https://lore.kernel.org/git/_/text/config/raw
so shell scripters w/o JSON parsers can use "git config"
I just had a look at its contents:
-- snip --
; example public-inbox config snippet for "git"
; see public-inbox-config(5) manpage for more details:
; https://public-inbox.org/public-inbox-config.html
[publicinbox "git"]
inboxdir = /path/to/top-level-inbox
; note: public-inbox before v1.2.0 used "mainrepo"
; instead of "inboxdir", both remain supported after 1.2
mainrepo = /path/to/top-level-inbox
address = git@vger.kernel.org
listid = git.vger.kernel.org
filter = PublicInbox::Filter::Mirror
newsgroup = org.kernel.vger.git
nntpmirror = nntp://nntp.lore.kernel.org/org.kernel.vger.git
-- snap --
Isn't `inboxdir` and `mainrepo` incorrect?
How so? It's fine to have both in case users need to downgrade
to older versions of public-inbox.
And yes, adding `epoch` information there would be very welcome.
Noted. Not sure if the "modified" and "fingerprint" keys of
manifest would make sense there, too...
From: Johannes Schindelin <hidden> Date: 2019-11-29 09:32:48
Hi Eric,
On Thu, 28 Nov 2019, Eric Wong wrote:
Johannes Schindelin [off-list ref] wrote:
quoted
Hi Eric,
On Thu, 28 Nov 2019, Eric Wong wrote:
quoted
Johannes Schindelin [off-list ref] wrote:
quoted
And: if I want to track the latest mails in GitGitGadget, what indication
will I have that I'll need to switch to `.../1`?
You can use the gzipped JSON grokmirror manifest at:
https://lore.kernel.org/git/manifest.js.gz
grokmirror could be a bit of a pain to install because of Python
dependencies, so periodically attempting to clone the next
numbered epoch ought to be fine, too.
I've also considered adding epoch info into
https://lore.kernel.org/git/_/text/config/raw
so shell scripters w/o JSON parsers can use "git config"
I just had a look at its contents:
-- snip --
; example public-inbox config snippet for "git"
; see public-inbox-config(5) manpage for more details:
; https://public-inbox.org/public-inbox-config.html
[publicinbox "git"]
inboxdir = /path/to/top-level-inbox
; note: public-inbox before v1.2.0 used "mainrepo"
; instead of "inboxdir", both remain supported after 1.2
mainrepo = /path/to/top-level-inbox
address = git@vger.kernel.org
listid = git.vger.kernel.org
filter = PublicInbox::Filter::Mirror
newsgroup = org.kernel.vger.git
nntpmirror = nntp://nntp.lore.kernel.org/org.kernel.vger.git
-- snap --
Isn't `inboxdir` and `mainrepo` incorrect?
How so? It's fine to have both in case users need to downgrade
to older versions of public-inbox.
I must have misinterpreted the purpose of this URL, then. I thought that
was the configuration of _this_ instance, and that I could use the path
indicated by `mainrepo` to replace the `/_/text/config/raw` part of the
URL to get to the repo URL.
Is this just a template file, then?
quoted
And yes, adding `epoch` information there would be very welcome.
Noted. Not sure if the "modified" and "fingerprint" keys of
manifest would make sense there, too...
I have no idea what purpose they serve, so I have no opinion on this
question.
Thanks,
Dscho
From: Eric Wong <hidden> Date: 2019-11-29 09:59:16
Johannes Schindelin [off-list ref] wrote:
Hi Eric,
On Thu, 28 Nov 2019, Eric Wong wrote:
quoted
Johannes Schindelin [off-list ref] wrote:
quoted
Hi Eric,
On Thu, 28 Nov 2019, Eric Wong wrote:
quoted
Johannes Schindelin [off-list ref] wrote:
quoted
And: if I want to track the latest mails in GitGitGadget, what indication
will I have that I'll need to switch to `.../1`?
You can use the gzipped JSON grokmirror manifest at:
https://lore.kernel.org/git/manifest.js.gz
grokmirror could be a bit of a pain to install because of Python
dependencies, so periodically attempting to clone the next
numbered epoch ought to be fine, too.
I've also considered adding epoch info into
https://lore.kernel.org/git/_/text/config/raw
so shell scripters w/o JSON parsers can use "git config"
I just had a look at its contents:
-- snip --
; example public-inbox config snippet for "git"
; see public-inbox-config(5) manpage for more details:
; https://public-inbox.org/public-inbox-config.html
[publicinbox "git"]
inboxdir = /path/to/top-level-inbox
; note: public-inbox before v1.2.0 used "mainrepo"
; instead of "inboxdir", both remain supported after 1.2
mainrepo = /path/to/top-level-inbox
address = git@vger.kernel.org
listid = git.vger.kernel.org
filter = PublicInbox::Filter::Mirror
newsgroup = org.kernel.vger.git
nntpmirror = nntp://nntp.lore.kernel.org/org.kernel.vger.git
-- snap --
Isn't `inboxdir` and `mainrepo` incorrect?
How so? It's fine to have both in case users need to downgrade
to older versions of public-inbox.
I must have misinterpreted the purpose of this URL, then. I thought that
was the configuration of _this_ instance, and that I could use the path
indicated by `mainrepo` to replace the `/_/text/config/raw` part of the
URL to get to the repo URL.
Is this just a template file, then?
It's a config snippet that can be copy+pasted into
~/.public-inbox/config and edited to suit the local machine
(but also human-readable and git-config(1)-parseable)
Both "mainrepo" and "inboxdir" refer to local paths, not URLs,
currently. But it would be nice to access inboxes over WebDAV
or similar :>
quoted
quoted
And yes, adding `epoch` information there would be very welcome.
Noted. Not sure if the "modified" and "fingerprint" keys of
manifest would make sense there, too...
I have no idea what purpose they serve, so I have no opinion on this
question.
They're timestamps and checksums used to reduce the cost of
checking multiple repos for updates. It's hugely beneficial
when there's 100s or 1000s of repos to mirror. grokmirror only
makes one HTTP request to get manifest.js.gz, and only runs
fetches for ones that need updating.
It's a less useful for git@vger since there's only one epoch,
currently; and checking for the existence of a next one (1.git)
isn't that expensive.
From: Denton Liu <hidden> Date: 2019-12-02 19:26:22
We reference many mail archives that use opaque links. Even though many
have been around for a long time, they may still be liable to go down
(see Gmane) leaving us with dead links that we cannot reference in the
future. Replace these links with links to lore.kernel.org which use
Message-IDs so that if lore.kernel.org ever goes down, it will be much
easier to find these messages in the future.
My series is based on top of 'jk/lore-is-the-archive'.
Denton Liu (3):
doc: replace MARC links with lore.kernel.org
RelNotes: replace Gmane with real Message-IDs
doc: replace LKML link with lore.kernel.org
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/RelNotes/1.8.4.txt | 2 +-
Documentation/RelNotes/2.5.0.txt | 3 ++-
Documentation/RelNotes/2.8.3.txt | 4 ++--
Documentation/RelNotes/2.9.0.txt | 2 +-
Documentation/git-bisect-lk2009.txt | 2 +-
Documentation/gitcli.txt | 4 ++--
Documentation/technical/racy-git.txt | 2 +-
Documentation/user-manual.txt | 4 ++--
t/t6021-merge-criss-cross.sh | 2 +-
14 files changed, 18 insertions(+), 17 deletions(-)
Range-diff against v1:
1: 14167012a1 ! 1: 0f100f06c5 doc: replace MARC links with LKML
@@ Metadata
Author: Denton Liu [off-list ref]
## Commit message ##
- doc: replace MARC links with LKML
+ doc: replace MARC links with lore.kernel.org
Since we're now recommending lore.kernel.org, replace marc.info links
with lore.kernel.org.
Although MARC has been around for a long time, nothing lasts forever
(see Gmane). Since MARC uses opaque message identifiers, switching to
- LKML should be a strict improvement since, even if LKML goes
- down, the Message-ID will allow future readers to look up the referenced
- messages on any other archive.
+ lore.kernel.org should be a strict improvement since, even if
+ lore.kernel.org goes down, the Message-ID will allow future readers to
+ look up the referenced messages on any other archive.
We leave behind one reference to MARC in the README.md since it's a
perfectly fine mail archive for personal reading, just not for linking
2: ebb2328a02 ! 2: cad77e0989 RelNotes: replace Gmane with real Message-IDs
@@ Commit message
are definitely not in active use, they might be of historical interest
for future readers so let's ensure that mail references are more robust.
- Replace links to Gmane with links to LKML (which is our new preferred
- mailing list archive and has the Message-ID in the URL) and bare Gmane
- ID references with Message-IDs.
+ Replace links to Gmane with links to lore.kernel.org (which is our new
+ preferred mailing list archive and has the Message-ID in the URL) and
+ bare Gmane ID references with Message-IDs.
The Message-IDs were found by searching for "gmane:<id>" on
https://public-inbox.org/git/ and taking the resulting message.
@@ Documentation/RelNotes/2.8.3.txt: Fixes since v2.8.2
has been used in Cygwin packaged versions of Git for quite a while.
- See http://thread.gmane.org/gmane.comp.version-control.git/291853
- and http://thread.gmane.org/gmane.comp.version-control.git/275680.
-+ See https://lkml.org/git/20160419091055.GF2345@dinwoodie.org/
-+ and https://lkml.org/git/20150811100527.GW14466@dinwoodie.org/.
++ See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
++ and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/.
* "git replace -e" did not honour "core.editor" configuration.
@@ Documentation/RelNotes/2.9.0.txt: notes for details).
already enabled for the MinGW and plain Windows builds. It also
has been used in Cygwin packaged versions of Git for quite a while.
- See http://thread.gmane.org/gmane.comp.version-control.git/291853
-+ See https://lkml.org/git/20160419091055.GF2345@dinwoodie.org/
++ See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
* "merge-octopus" strategy did not ensure that the index is clean
when merge begins.
-: ---------- > 3: a7c8981ba5 doc: replace LKML link with lore.kernel.org
--
2.24.0.504.g3cd56eb17d
From: Denton Liu <hidden> Date: 2019-12-02 19:26:27
Since we're now recommending lore.kernel.org, replace marc.info links
with lore.kernel.org.
Although MARC has been around for a long time, nothing lasts forever
(see Gmane). Since MARC uses opaque message identifiers, switching to
lore.kernel.org should be a strict improvement since, even if
lore.kernel.org goes down, the Message-ID will allow future readers to
look up the referenced messages on any other archive.
We leave behind one reference to MARC in the README.md since it's a
perfectly fine mail archive for personal reading, just not for linking
messages for the future.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-bisect-lk2009.txt | 2 +-
Documentation/gitcli.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
t/t6021-merge-criss-cross.sh | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
@@ -205,8 +205,8 @@ only affects the files in the working tree, but with entries, and with `--cached`, it modifies only the index entries.-See also http://marc.info/?l=git&m=116563135620359 and-http://marc.info/?l=git&m=119150393620273 for further+See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and+https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ for further information. Some other commands that also work on files in the working tree and/or
@@ -4687,5 +4687,5 @@ Write a chapter on using plumbing and writing scripts. Alternates, clone -reference, etc. More on recovery from repository corruption. See:- http://marc.info/?l=git&m=117263864820799&w=2- http://marc.info/?l=git&m=117147855503798&w=2+ https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/+ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/
@@ -3,7 +3,7 @@# Copyright (c) 2005 Fredrik Kuivinen#-# See http://marc.info/?l=git&m=111463358500362&w=2 for a+# See https://lore.kernel.org/git/Pine.LNX.4.44.0504271254120.4678-100000@wax.eds.org/ for a# nice description of what this is about.
From: Denton Liu <hidden> Date: 2019-12-02 19:26:27
The only references to Gmane that remain are in RelNotes. Although these
are definitely not in active use, they might be of historical interest
for future readers so let's ensure that mail references are more robust.
Replace links to Gmane with links to lore.kernel.org (which is our new
preferred mailing list archive and has the Message-ID in the URL) and
bare Gmane ID references with Message-IDs.
The Message-IDs were found by searching for "gmane:<id>" on
https://public-inbox.org/git/ and taking the resulting message.
Signed-off-by: Denton Liu <redacted>
---
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/RelNotes/1.8.4.txt | 2 +-
Documentation/RelNotes/2.5.0.txt | 3 ++-
Documentation/RelNotes/2.8.3.txt | 4 ++--
Documentation/RelNotes/2.9.0.txt | 2 +-
9 files changed, 11 insertions(+), 10 deletions(-)
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -11,7 +11,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -22,7 +22,7 @@ push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition plan.
@@ -64,7 +64,7 @@ users will fare this time. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare- http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/ for more details on the reason why this change is needed and the transition process that already took place so far.
@@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports. credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that- this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it+ this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has
@@ -172,7 +172,8 @@ Performance, Internal Implementation, Development Support etc. incorrect patch text to "git apply". Add tests to demonstrate this.- I have a slight suspicion that this may be $gmane/87202 coming back+ I have a slight suspicion that this may be+ cf. <7vtzf77wjp.fsf@gitster.siamese.dyndns.org> coming back and biting us (I seem to have said "let's run with this and see what happens" back then).
@@ -55,8 +55,8 @@ Fixes since v2.8.2 This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while.- See http://thread.gmane.org/gmane.comp.version-control.git/291853- and http://thread.gmane.org/gmane.comp.version-control.git/275680.+ See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/+ and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/. * "git replace -e" did not honour "core.editor" configuration.
@@ -368,7 +368,7 @@ notes for details). This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. It also has been used in Cygwin packaged versions of Git for quite a while.- See http://thread.gmane.org/gmane.comp.version-control.git/291853+ See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/ * "merge-octopus" strategy did not ensure that the index is clean when merge begins.
From: Denton Liu <hidden> Date: 2019-12-02 19:26:27
Since we're now recommending lore.kernel.org, replace LKML link
with lore.kernel.org.
Although LKML has been around for a long time, nothing lasts forever
(see Gmane). Since LKML uses opaque message identifiers, switching to
lore.kernel.org should be a strict improvement since, even if
lore.kernel.org goes down, the Message-ID will allow future readers to
look up the referenced messages on any other archive.
Signed-off-by: Denton Liu <redacted>
---
Documentation/technical/racy-git.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -51,7 +51,7 @@ of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git only fixes the issue for file systems with exactly 1 ns or 1 s resolution. Other file systems are still broken in current Linux kernels (e.g. CEPH, CIFS, NTFS, UDF), see-https://lkml.org/lkml/2015/6/9/714+https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/ Racy Git --------