Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Eric, > > > On Thu, 17 Oct 2019, Eric Wong wrote: > > > (WIP, mostly stream-of-concious notes + reasoning) > > > > When using "git format-patch --range-diff", the pre and > > post-image blob OIDs are in each email, while the exact > > commit OIDs are rarely shared via emails (only the tip > > commit from "git request-pull"). > > > > These blob OIDs make it easy to search for or lookup the > > full emails which create them, or the blob itself once > > it's fetched via git. > > > > public-inbox indexes and allows querying specifically for blob > > OIDs via dfpre:/dfpost: since June 2017. As of Jan 2019, > > public-inbox also supports recreating blobs out of patch emails > > (querying internally with dfpre:/dfpost: and doing "git apply") > > > > Searching on these blob OIDs also makes it easier to find > > previous versions of the patch sets using any mail search > > engine. > > > > Future changes to public-inbox may allow generating custom > > diffs out of any blobs it can find or recreate. > > > > Most of this is pretty public-inbox-specific and would've > > made some future changes to public-inbox much easier.... > > (if we had this from the start of range-diff). > > > > Unfortunately, it won't help with cases where range-diffs > > are already published, but range-diff isn't too old. > > I guess your patch won't hurt.
Cool, will update tests and resend. > As to recreating blobs from mails: Wow. That's quite a length you're > going, and I think it is a shame that you have to. If only every contribution came accompanied with a pullable branch in a public > repository. What Konstantin said about git repos being transient. It wasn't too much work to recreate those blobs from scratch since git-apply has done it since 2005. Just add search :) We could get around transient repos with automatic mirroring bots which never deletes or overwrites anything published. That includes preserving pre-force-push data in case of force pushes. > 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. The only thing that's centralized and not reproducible by mirrors is the domain name (and I also have Tor .onion mirrors with no dependency on ICAAN). Memorable naming is a tricky problem in decentralized systems, though...
