Re: [RFC/WIP] range-diff: show old/new blob OIDs in comments
- From
- Eric Wong <e@80x24.org>
- Date
- Oct 23, 2019, 01:56 UTC
- Message-ID
- <20191023015629.GA15495@dcvr>
- In-Reply-To
- <nycvar.QRO.7.76.6.1910222111430.46@tvgsbejvaqbjf.bet>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 36 quoted lines
> 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...