git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

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

Previous: Konstantin RyabitsevNext: Junio C Hamano
Message 4 of 9 in “[RFC/WIP] range-diff: show old/new blob OIDs in comments”
  1. Eric WongOct 17, 2019
  2. Johannes SchindelinOct 22, 2019
  3. Konstantin RyabitsevOct 22, 2019
  4. Eric WongOct 23, 2019
  5. Junio C HamanoOct 23, 2019
  6. Johannes SchindelinOct 24, 2019
  7. Eric WongOct 25, 2019
  8. Johannes SchindelinOct 25, 2019
  9. Eric WongOct 23, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.