user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org
Subject: Re: Threading in git repo?
Date: Mon, 18 Mar 2019 16:38:17 -0500	[thread overview]
Message-ID: <20190318213817.GA88541@google.com> (raw)
In-Reply-To: <20190314074447.GA8156@dcvr>

On Thu, Mar 14, 2019 at 07:44:47AM +0000, Eric Wong wrote:
> Bjorn Helgaas <helgaas@kernel.org> wrote:
> > As far as I can tell, pi git repos have no branching: each new message
> > is added as a child commit of the most recent message, even if it is a
> > response to an older message.  Have you considered making the new
> > message a child of the message it is responding to?
> 
> Correct, there is no branching.  Doing threading in git does not
> work because of out-of-order message delivery (which is common
> in SMTP).  public-inbox-index scanning (along with notmuch and
> mairix) are all resilient to out-of-order message delivery when
> doing threading.

Oh, I hadn't thought about out-of-order delivery.  That definitely is
a problem.

> > I'm fiddling with making neomutt read a pi git repo.  Currently I only
> > read the git log info (not the commit bodies).  It's pretty fast to
> > read the author, date, and subject (since you conveniently stash them
> > in the commit metadata), but since I'm not reading the mail headers,
> > neomutt can't do all its threading magic.
> 
> neomutt could read the over.sqlite3 database...
> However, I can't guarantee it's stability, either (since it's
> in the "xap$VER" directory where $VER is 15, now).
> 
> Perhaps improving NNTP support in neomutt is the best way to go?

I'm still hoping to get to a solution using a local public-inbox
archive, without requiring a network connection or even additional
local servers.

> If the git commit messages all had key headers
> (Message-ID/From/To/Cc/References/In-Reply-To/Subject), then
> yes; then a SQLite/Xapian-agnostic client could be taught to
> read and do threading based on that; with fewer git ODB
> accesses.  I don't think it's worth introducing at this
> time, though.

If I understand correctly (sorry, I'm a newbie to public-inbox and git
internals) you're saying that one approach would be to copy some of
the headers from the message body into the commit message, which means
they'd be in the git "commit" object in addition to being in the blob,
which in turn would mean a client could do threading by reading only
the commit objects without reading the tree and blob objects.

I agree that's probably not worthwhile because it seems a little
kludgy and would only reduce the number of objects to read by a factor
of three.

Bjorn

  reply	other threads:[~2019-03-19  2:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13 23:07 Threading in git repo? Bjorn Helgaas
2019-03-14  7:44 ` Eric Wong
2019-03-18 21:38   ` Bjorn Helgaas [this message]
2019-03-18 23:04     ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190318213817.GA88541@google.com \
    --to=helgaas@kernel.org \
    --cc=e@80x24.org \
    --cc=meta@public-inbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).