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

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

 



Hi Eric,

On Fri, 25 Oct 2019, Eric Wong wrote:

> 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.

I am _more_ than happy to rely on public-inbox.org/git. And I will never
kid myself about relying on a central service, is all.

> 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.

Well, too bad. I trust you, Eric. I do trust you and will probably
continue to trust you because I don't expect you to do anything, ever,
to break that trust. So far, you haven't disappointed me even a single
time, and we've concurrently been Git contributors for, sheesh, has it
already been almost 14 years? I have benefitted from your work greatly,
mostly via `git svn` in the olden days, and I hope that I could return
the favor every once in a while.

Without public-inbox.org/git, GitGitGadget would not be possible. My
scripts to map commits to mails and vice versa (mirrored to
https://github.com/gitgitgadget/git as `refs/notes/mail-to-commit` and
`commit-to-mail`) would remain a pipe dream of mine.

(Yes, yes, there are holes in that mapping, but even if I only have to
look up manually one out of 30 mails when I want to comment on a
specific commit, that already saves me so much time, not to mention
nerves.)

So please understand that I am deeply grateful that you came up with
these projects, in particular with public-inbox. It is a life saver. I
might not share all of your philosophy regarding centralized vs
decentralized, even so, what you did helps me multiple times every
single day.

Therefore: a heart-felt Thank You, I owe you more than one,
Dscho




[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