On Wed, Mar 29, 2023 at 3:50 AM Michael J Gruber
<michaeljgruber+grubix+...@gmail.com> wrote:
> Am Mi., 29. März 2023 um 10:41 Uhr schrieb Felipe Contreras
> <felipe.contre...@gmail.com>:
> >
> > Hi,
> >
> > I noticed you promoted notmuch-git as a user tool to toy around with it.
> >
> > Very quickly I realized that most of what it does is something I've
> > been working on for at least 10 years: making git work with other
> > tools.
> >
> > I presume you haven't heard of git remote-helpers [1], because they do
> > precisely what notmuch-git is trying to do.
> >
> Hi Felipe
> that's an interesting idea for sure. When I came across `notmuch-git`
> first I wondered whether it rather should be`git-notmuch`, i.e. a
> subcommand to `git`. I admit that - given its preexistence as nmbug -
> I was never quite sure what to use it for. Maybe sync tags for mail
> stores whose content you sync otherwise? `public-inbox` came to my
> mind in this context, too. (I wondered about an nm backend for that,
> i.e. a public-inbox backed mailstore for notmuch, without multiple
> checkouts.)

Yes, I also thought of a public-inbox backend for notmuch, but for
that some notion of virtual files should probably be introduced, and I
think at the moment the current code of notmuch relies on real files.

> So, if we consider the notmuch database (more precisely: the dump
> output) as a "remote", then what is the history? I understand that we
> can transfer and transform its content in the form of blobs as
> specific paths encoding mid etc. Is the history stored by current
> `notmuch-git` something secondary (say, like the history of notes refs
> in git) which can be discarded?

The history is arbitrarily created.

Say you have two `git-remote-nm` repositories keeping track of the
same notmuch database. Except one does a daily `git fetch`, and the
other does it once a month. The former is going to have many more
commits, and thus a more granular history.

Think of it as a `git fetch` just being a simpler version of some
custom `notmuch dump | convert-script | git commit`.

> Note that I haven't looked at your code thoroughly yet (I'm not a
> rubyist),

You don't need to be a rubyist, just copy the script anywhere in your
path, and clone your mail database. As long as you never do `git
push`, the operations are going to be read-only, but if you want to be
extra safe, remove " mode: Notmuch::MODE_READ_WRITE" from the code,
and/or copy the mail database somewhere temporary.

Do `git fetch` regularly, and you'll see how a history of
"origin/master" is being created.

> and I'm all for using git tools to do gittish things and
> more; I'm just wondering whether fast-import/export cover what current
> `notmuch-git` intends to do. They are probably the best tool for
> "cloning"  an existing nm-db into a git repo of mid-tag associations.
> And if all you want is a gittish transport for nm tags then that's
> probably perfect!
> `notmuch-git` seems to be about handling both updates (commit etc)

You can do the same with `git-notmuch`: just do `git commit`.

I do that in the tests to add a tag [1].

> and queries (log etc),

Ditto: just do `git log`.

If you look at the code of `notmuch-git`, it's just a wrapper for `git
log --name-status --no-renames`.

> In summary, I think a notmuch-git repo is more than a conversion of
> notmuch-dump output (it adds history and commit messages; we have a
> "one-sided inverse" only), and the notmuch-git command is more than a
> converter between the respective data stores.

So is `git-notmuch`: every time you do `git fetch` a commit is created.

The history is all there.



Felipe Contreras
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Reply via email to