linux-kernel - Re: email as a bona fide git transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191018022253.GA29290@dcvr>
Date:   Fri, 18 Oct 2019 02:22:53 +0000
From:   Eric Wong <e@...24.org>
To:     Vegard Nossum <vegard.nossum@...cle.com>
Cc:     workflows@...r.kernel.org, git@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: email as a bona fide git transport

Vegard Nossum <vegard.nossum@...cle.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