On Wed, Mar 29, 2023 at 3:50 AM Michael J Gruber <michaeljgruber+grubix+git@gmail.com> wrote: > > Am Mi., 29. März 2023 um 10:41 Uhr schrieb Felipe Contreras > <felipe.contreras@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. Cheers. [1] https://github.com/felipec/git-notmuch/blob/cdb2954abf3eb9f2f04f71fd2385a34653f758f5/t/basic.t#L87 -- Felipe Contreras _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org