Vegard Nossum <vegard.nos...@oracle.com> wrote: <snip> > Disadvantages: > > - requires patching git
The bigger disadvantage is this won't work with a historical patch series (and some folks stay on ancient git). But maybe that window for that is only a few years... The toughest part right now for public-inbox is trying to make sense of --range-diff (supporting --interdiff would be easy, I think...). Also, we've only had --range-diff for a year or so. Your proposal would make things 100% easier for public-inbox to deal with future --range-diff uses, however :) > - requires a bot to continuously create branches for patchsets sent to > mailing lists Not necessarily, being able to search on commit OIDs would be pretty handy itself for dealing with --range-diff output in public-inbox, so there's no real need to actually make the branch in git. I also have a parallel solution in the works to make --range-diff output more amenable for search engines like public-inbox by adding blob OIDs to its output: https://public-inbox.org/git/20191017121045.GA15364@dcvr/ I shall call myself an "SEO expert" from now on :> > Thoughts? Pretty much the same concerns others brought up around exactness and working on top of cherry-picks. > PS: Eric Wong described something that comes quite close to this idea, but > AFAICT without actually recreating commits exactly. I've included the link > for completeness. [4] > [4]: https://lore.kernel.org/workflows/20191008003931.y4rc2dp64gbhv5ju@dcvr/ My plan is to work on interdiff support in the next week or so once bugs are fixed and public-inbox v1.2 is out the door. Not sure about range-diff and reverse-mapping blobs -> trees -> commits, but searching on "git patch-id --stable" output is also on the table. PS: Attached patches: I have nothing against using MIME for those, (not speaking for anybody else). public-inbox needs to handle those better w.r.t search indexing linkification. And then I found some bugs for --reindex corner cases which I'm still working on :x
