Re: [RFC/WIP] range-diff: show old/new blob OIDs in comments

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

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> On Wed, 23 Oct 2019, Junio C Hamano wrote:
> > Eric Wong <e@xxxxxxxxx> writes:
> > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > >> Instead, we will have to rely on your centralized, non-distributed
> > >> service...
> > >
> > > I'm curious how you came to believe that, since that's the
> > > opposite of what public-inbox has always been intended to be.
> >
> > I think the (mis)perception comes from the fact that the website and
> > the newsfeed you give are both too easy to use and directly attract
> > end users, instead of enticing them to keep their own mirrors for
> > offline use.
> >
> > Thanks for injecting dose of sanity.
> 
> Maybe your dose of sanity can inject a statement about the case when
> public-inbox.org/git differs from a mirror, and not in a
> fast-forwardable way? What is the authoritative source of truth, then?

Why does authoritative source of truth matter?  My
anti-authoritarian ethos is what drew me to DVCS in the first
place.

If senders want to attest to the integrity of their messages;
they can sign, and/or publish a copy/log of their sent messages
on their homepage/social media/whatever.  That's up to THEM,
not anybody else.

If somebody wants to fork public-inbox.org/git and run
public-inbox-watch from their own Maildir, they're more than
welcome to.

If somebody wants to write their own importers since they don't
like the code I write, they are more than welcome to.  There's
already mail-archive.com, marc.info, news.gmane.org (which
public-inbox.org/git forked from) and some others.

Going farther, if people want to fork entire mailing lists and
communities, they should be able to do so.  I don't like mail
subscriber lists being centralized on any host, either.

I have never, ever asked anybody to trust me or public-inbox;
in fact, I've stated the opposite and will continue to do so.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux