Am Fr., 23. Aug. 2024 um 17:46 Uhr schrieb Martin Jambor :
>
> Hi,
>
> On Thu, Aug 22 2024, Michael J Gruber wrote:
> > Am Do., 22. Aug. 2024 um 14:37 Uhr schrieb Martin Jambor :
> >>
> >> Hi,
> >>
> >> I have noticed that notmuch-git was not
Hi,
On Thu, Aug 22 2024, Michael J Gruber wrote:
> Am Do., 22. Aug. 2024 um 14:37 Uhr schrieb Martin Jambor :
>>
>> Hi,
>>
>> I have noticed that notmuch-git was not being copied to an appropriate
>> destination during make install. This patch adds that.
>>
Michael J Gruber writes:
> notmuch-git(1) mentions nmbug, so we'd want to install that as well, don't we?
>
FWIW, we do in Debian. But I am probably biased as one of the main users
of nmbug and the Debian package maintainer.
d
___
Am Do., 22. Aug. 2024 um 14:37 Uhr schrieb Martin Jambor :
>
> Hi,
>
> I have noticed that notmuch-git was not being copied to an appropriate
> destination during make install. This patch adds that.
>
> ---
> Makefile.local | 1 +
> 1 file changed, 1 insertion(+)
>
Hi,
I have noticed that notmuch-git was not being copied to an appropriate
destination during make install. This patch adds that.
---
Makefile.local | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.local b/Makefile.local
index 7699c208..34e8b882 100644
--- a/Makefile.local
+++ b
> I would rather go for a solution that is less hacky, and has less
> chance of leaving the user in an unrecoverable state.
fair enough. Certainly notmuch-git has too many accumulated performance
hacks.
___
notmuch mailing list -- notmuch@notmuchmail.or
On Tue, Apr 4, 2023 at 12:54 PM David Bremner wrote:
>
> Felipe Contreras writes:
>
> > On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote:
>
> > Or we could say that after jumping a certain threshold of lastmod we
> > delete all the messages and start from scratch, perhaps every 1000
> > revisi
Felipe Contreras writes:
> On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote:
> Or we could say that after jumping a certain threshold of lastmod we
> delete all the messages and start from scratch, perhaps every 1000
> revisions.
>
> Or maybe the query could generate a virtual tag if a messag
ere. I still have to try some merges between different
machines to see what kind of conflicts can arise.
> One advantage of using the fast-import format is that it's easy to
> change it, or support multiple formats.
>
> In fact, the format could be specified in the URL, like
> `n
;s easy to
change it, or support multiple formats.
In fact, the format could be specified in the URL, like
`nm::1:$HOME/mail` for the current notmuch-git format, and
`nm::2:$HOME/mail` for the new.
--
Felipe Contreras
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote:
>
> Felipe Contreras writes:
>
> >
> > That should work to update existing tags, but how are we going to
> > detect if a message has disappeared? Or is that not a thing?
>
> Indeed the same thought had occurred to me not long ago. I remembered
>
Felipe Contreras writes:
>
> That should work to update existing tags, but how are we going to
> detect if a message has disappeared? Or is that not a thing?
Indeed the same thought had occurred to me not long ago. I remembered
(belately) that I'd been through some similar thought process with n
xperiments. I had to
> remove the 'deleteall' (otherwise only the changed messages are left
> in the git repo). I'm not 100% this is correct, hopefully you see
> quicker than I. In any case the lastmod query is what notmuch-git
> uses.
That should work to upd
astmod value, you should be able to use it in a
query. This does make a big difference in my experiments. I had to
remove the 'deleteall' (otherwise only the changed messages are left
in the git repo). I'm not 100% this is correct, hopefully you see
quicker than I. In any cas
Felipe Contreras writes:
> By distributing the files in multiple directories like notmuch-git
> does using BLAKE2b, the operation is much faster.
>
> I've pushed the changes, now there's a dependency, but you can just
> `gem install blake2b`.
>
> I'm able to c
ast, but for comparison an initial (i.e. fresh
> repo, no caching) "notmuch git commit" takes about 15-20s.
I found the problem. If all the files are in the same directory, `git
fast-import` spends a lot of time comparing all the paths.
By distributing the files in multiple directories li
On Mon, Apr 3, 2023 at 4:49 AM David Bremner wrote:
>
> Felipe Contreras writes:
>
> > 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'
David Bremner writes:
>
> I'm intrigued (and indeed I hadn't really thought about the degree to
> which we were re-inventing git-fast-import and friends); however so far
> my experiments did not get far enough to say anything conclusive.
>
I did manage to finish, about 70 minutes elapsed.
Altho
Felipe Contreras writes:
> 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
On Wed, Mar 29, 2023 at 3:50 AM Michael J Gruber
wrote:
>
> Am Mi., 29. März 2023 um 10:41 Uhr schrieb Felipe Contreras
> :
> >
> > Hi,
> >
> > I noticed you promoted notmuch-git as a user tool to toy around with it.
> >
> > Very quickly I realize
Am Mi., 29. März 2023 um 10:41 Uhr schrieb Felipe Contreras
:
>
> 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 g
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], becau
Tomi Ollila writes:
>> +
>> +
>
> Is three empty lines a bit excessive...?
>
>> +time_done
Fixed in git.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
ce-test/T07-git.sh
>
> diff --git a/performance-test/T07-git.sh b/performance-test/T07-git.sh
> new file mode 100755
> index ..11dfec05
> --- /dev/null
> +++ b/performance-test/T07-git.sh
> @@ -0,0 +1,23 @@
> +#!/usr/bin/env bash
> +
> +test_description='n
-test/T07-git.sh
new file mode 100755
index ..11dfec05
--- /dev/null
+++ b/performance-test/T07-git.sh
@@ -0,0 +1,23 @@
+#!/usr/bin/env bash
+
+test_description='notmuch-git'
+
+. $(dirname "$0")/perf-test-lib.sh || exit 1
+
+time_start
+
+time_run 'init' "no
This series speeds up "notmuch git checkout" from "intolerably slow"
to "OKish" on my mail.
[PATCH 1/4] debian: add git as a build-dependency, for the test suite
This is unrelated to the rest of the series, but needed to build the
debian package
[PATCH
From: Michael J Gruber
8ed68c1b ("CLI/git: change defaults for repo and prefix", 2022-05-07)
introduced an nmbug symlink for the notmuch-git man page. Do the same
for the info page.
Signed-off-by: Michael J Gruber
---
While I don't use info pages personally, I package them ...
Old repos (in particular nmbug) should keep working transparently, but
new ones will be created with a couple of layers of hashed directories
to avoid problems with (at least) ext4 file systems and too many
subdirectories in a given directory.
There is no history preserving upgrade path in this se
It turns out that if you have more than about 150k messages _and_ your
/tmp is on ext4, then the merge operation for notmuch-git can fail
(either hash collisions in the directory indexing, or running out of
inodes). There are few possible solutions. The simplest is just to
make /tmp tmpfs. Another
208 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -45,6 +45,15 @@ $(SHA256_FILE): $(TAR_FILE)
$(DETACHED_SIG_FILE): $(TAR_FILE)
gpg --armor --detach-sign $^
+CLEAN := $(CLEAN) notmuch-git
+notmuch-git: notmuch-git.py
+ cp $< $@
+ chmod ugo+x $@
+
+CLEAN := $(CLEAN) nmbug
insertions(+)
create mode 100644 doc/man1/notmuch-git.rst
diff --git a/doc/conf.py b/doc/conf.py
index e4bad9f1..f01c0058 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -123,6 +123,10 @@ man_pages = [
u'send mail with notmuch and emacs',
[notmuch_authors], 1),
+ ('m
the notmuch command-line interface
+Package: notmuch-git
+Architecture: all
+Depends:
+ git,
+ notmuch,
+ python3,
+ ${misc:Depends}
+Description: thread-based email index, search and tagging
+ Notmuch is a system for indexing, searching, reading, and tagging
+ large collections of email messages
Exercise the main functionality of notmuch-git. add_git_repos() will
hopefully be simplifed when an init subcommand is added.
---
notmuch-git.py | 4 +++
test/T850-git.sh | 93
2 files changed, 97 insertions(+)
create mode 100755 test/T850
It is often more convenient to use command line arguments than
environment variables.
---
notmuch-git.py | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/notmuch-git.py b/notmuch-git.py
index fb42e5bf..34d07125 100644
--- a/notmuch-git.py
+++ b/
thon-cffi-bindings
+all: notmuch notmuch-shared build-man build-info ruby-bindings
python-cffi-bindings notmuch-git
ifeq ($(MAKECMDGOALS),)
ifeq ($(shell cat .first-build-message 2>/dev/null),)
@NOTMUCH_FIRST_BUILD=1 $(MAKE) --no-print-directory all
@@ -45,6 +45,11 @@ $(SHA256_FILE)
Exercise the main functionality of notmuch-git. add_git_repos() will
hopefully be simplifed when an init subcommand is added.
---
notmuch-git.in | 4 +++
test/T850-git.sh | 93
2 files changed, 97 insertions(+)
create mode 100755 test/T850
This is mainly derived from the various help outputs from the script,
with some massaging of markup and addition of links.
Define notmuch-git as a known external command. This will allow
"notmuch help git" to invoke man notmuch-git, rather than erroring
out.
---
doc/conf.py
It is often more convenient to use command line arguments than
environment variables.
---
notmuch-git.in | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/notmuch-git.in b/notmuch-git.in
index 5d6e29f0..4b94046d 100755
--- a/notmuch-git.in
+++ b/
the notmuch command-line interface
+Package: notmuch-git
+Architecture: all
+Depends:
+ git,
+ notmuch,
+ python3,
+ ${misc:Depends}
+Description: thread-based email index, search and tagging
+ Notmuch is a system for indexing, searching, reading, and tagging
+ large collections of email messages
python-cffi-bindings notmuch-git
ifeq ($(MAKECMDGOALS),)
ifeq ($(shell cat .first-build-message 2>/dev/null),)
@NOTMUCH_FIRST_BUILD=1 $(MAKE) --no-print-directory all
@@ -294,7 +294,7 @@ endif
SRCS := $(SRCS) $(notmuch_client_srcs)
CLEAN := $(CLEAN) notmuch notmu
20621-1-da...@tethera.net
diff --git a/Makefile.local b/Makefile.local
index ca2310f4..0fadfb26 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -1,7 +1,7 @@
# -*- makefile-gmake -*-
.PHONY: all
-all: notmuch notmuch-shared build-man build-info ruby-bindings
python-cffi-bindings notmuch-
The intent is to change the names of the environment variables before
releasing this code, so avoid relying on environment variables in the
test framework.
---
notmuch-git.in | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/notmuch-git.in b/notmuch-git.in
ind
python-cffi-bindings notmuch-git
ifeq ($(MAKECMDGOALS),)
ifeq ($(shell cat .first-build-message 2>/dev/null),)
@NOTMUCH_FIRST_BUILD=1 $(MAKE) --no-print-directory all
@@ -294,7 +294,7 @@ endif
SRCS := $(SRCS) $(notmuch_client_srcs)
CLEAN := $(CLEAN) notmuch notmu
The test suite will require setting the tag prefix (at least
initially), and this commit will enable doing that without relying on
environment variables (whose names are planned to change).
---
notmuch-git.in | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/notmuch
a/debian/control b/debian/control
index a11d4130..9706b0f7 100644
--- a/debian/control
+++ b/debian/control
@@ -66,6 +66,22 @@ Description: thread-based email index, search and tagging
.
This package contains the notmuch command-line interface
+Package: notmuch-git
+Architecture: all
+Depends
Exercise the main functionality of notmuch-git. add_git_repos() will
hopefully be simplifed when an init subcommand is added.
---
test/T850-git.sh | 95
1 file changed, 95 insertions(+)
create mode 100755 test/T850-git.sh
diff --git a/test/T850
..d682141f 100755
--- a/test/T850-git.sh
+++ b/test/T850-git.sh
@@ -3,13 +3,7 @@ test_description='"notmuch git" to save and restore tags'
. $(dirname "$0")/test-lib.sh || exit 1
add_git_repos () {
- # first the equivalent of "notmuch git init" (which doesn
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -123,6 +123,10 @@ man_pages = [
u'send mail with notmuch and emacs',
[notmuch_authors], 1),
+ ('man1/notmuch-git', 'notmuch-git',
+ u'manage notmuch tags with git',
+ [notmuch_authors], 1),
+
On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins
wrote:
> Once the project becomes more mature and other developers are
> vetting patches, then their branches can take over as "master" in the
> absence of an outdated canonical master.
The other thing that will happen as the project matures is
On Wed, 03 Feb 2010 22:58:05 -0500, Jameson Rollins wrote:
> Once the project becomes more mature and other developers are
> vetting patches, then their branches can take over as "master" in the
> absence of an outdated canonical master.
The other thing that will happen as the project matures is
On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari wrote:
> I agree. There is no good reason to switch away from the existing
> infrastructure. If he wants, Carl can give regular contributors their
> own repositories on notmuchmail.org if some people have difficulties
> providing it themselves. After
On Wed, 27 Jan 2010 14:17:39 -0500, Ben Gamari wrote:
> I agree. There is no good reason to switch away from the existing
> infrastructure. If he wants, Carl can give regular contributors their
> own repositories on notmuchmail.org if some people have difficulties
> providing it themselves. After
also sprach racin at free.fr [2010.02.18.2134 +1300]:
> I don't understand the problem. Why not just letting all "inbox"
> mails in a regular Maildir, and use git only when they have been
> explicit archived?
I don't archive my mail. I would like to be able to bring mails from
the past back into
also sprach ra...@free.fr [2010.02.18.2134 +1300]:
> I don't understand the problem. Why not just letting all "inbox"
> mails in a regular Maildir, and use git only when they have been
> explicit archived?
I don't archive my mail. I would like to be able to bring mails from
the past back into cir
also sprach martin f krafft [2010.02.18.1500 +1300]:
> > > If we keep ancestry though, we are reusing existing working code for
> > > backup (git-pull :)
> >
> > This is one of the reasons I feel it's important we keep it. And as is
> > stated below, the storage overhead is minimal.
>
> Absolute
- "martin f krafft" a ?crit :
> Except I fear that as soon as we allow manipulation of the local
> store, we'll potentially run into this problem:
>
> http://notmuchmail.org/pipermail/notmuch/2010/001114.html
> id:20100112045152.GA15275 at lapse.rw.madduck.net
I don't understand the pr
Excerpts from racin's message of Thu Feb 18 03:34:28 -0500 2010:
>
> - "martin f krafft" a ?crit :
>
> > Except I fear that as soon as we allow manipulation of the local
> > store, we'll potentially run into this problem:
> >
> > http://notmuchmail.org/pipermail/notmuch/2010/001114.html
>
On Thu, 18 Feb 2010 09:34:28 +0100 (CET), racin at free.fr wrote:
> I don't understand the problem. Why not just letting all "inbox" mails in a
> regular Maildir,
> and use git only when they have been explicit archived? This way, mails are
> added to git only if we want
> to save them, and we r
Excerpts from racin's message of Thu Feb 18 03:34:28 -0500 2010:
>
> - "martin f krafft" a écrit :
>
> > Except I fear that as soon as we allow manipulation of the local
> > store, we'll potentially run into this problem:
> >
> > http://notmuchmail.org/pipermail/notmuch/2010/001114.html
>
On Thu, 18 Feb 2010 09:34:28 +0100 (CET), ra...@free.fr wrote:
> I don't understand the problem. Why not just letting all "inbox" mails in a
> regular Maildir,
> and use git only when they have been explicit archived? This way, mails are
> added to git only if we want
> to save them, and we rare
- "martin f krafft" a écrit :
> Except I fear that as soon as we allow manipulation of the local
> store, we'll potentially run into this problem:
>
> http://notmuchmail.org/pipermail/notmuch/2010/001114.html
> id:20100112045152.ga15...@lapse.rw.madduck.net
I don't understand the probl
also sprach martin f krafft [2010.02.18.1500 +1300]:
> > > If we keep ancestry though, we are reusing existing working code for
> > > backup (git-pull :)
> >
> > This is one of the reasons I feel it's important we keep it. And as is
> > stated below, the storage overhead is minimal.
>
> Absolute
On Mon, Jan 25, 2010 at 01:46:59PM +1300, martin f krafft wrote:
> Stewart, you've worked most on this so far. Would you like to share
> your thoughts?
Just posted a new thread with my latest experiments. Things look
rather good from a storage size point of view. Still a few things to
work out tho
On Mon, Jan 25, 2010 at 01:46:59PM +1300, martin f krafft wrote:
> Stewart, you've worked most on this so far. Would you like to share
> your thoughts?
Just posted a new thread with my latest experiments. Things look
rather good from a storage size point of view. Still a few things to
work out tho
also sprach Carl Worth [2010.02.07.1156 +1300]:
> > Sorry to burden you, but since you want to continue maintaining
> > the infrastructure, that's just what I have to do. ;)
>
> No burden at all. I don't really care to do everything alone.
> I just want to ensure we keep things centralized enough
also sprach Carl Worth [2010.02.07.1156 +1300]:
> > Sorry to burden you, but since you want to continue maintaining
> > the infrastructure, that's just what I have to do. ;)
>
> No burden at all. I don't really care to do everything alone.
> I just want to ensure we keep things centralized enough
On Thu, 4 Feb 2010 19:38:07 +1300, martin f krafft wrote:
> Carl, could you set up notmuch-comm...@notmuchmail.org and enable
> the commit and enable the mail hook as per
Doing that now.
> Sorry to burden you, but since you want to continue maintaining the
> infrastructure, that's just what I ha
On Thu, 4 Feb 2010 19:38:07 +1300, martin f krafft
wrote:
> Carl, could you set up notmuch-commits at notmuchmail.org and enable
> the commit and enable the mail hook as per
Doing that now.
> Sorry to burden you, but since you want to continue maintaining the
> infrastructure, that's just what
also sprach Servilio Afre Puentes [2010.02.04.1918
+1300]:
> > If there is indeed an RSS/Atom feed on gitweb that includes the
> > diffs inline, please give me the URL; I can't fine ond.
>
> Can't see that even in the code.
Carl, could you set up notmuch-commits at notmuchmail.org and enable
th
also sprach Servilio Afre Puentes [2010.02.04.1714
+1300]:
> In the second link, the links with the text "commitdiff" provide
> it, and you have the Atom and RSS feeds at the bottom.
As I see it, the feeds have links to the commitdiffs, but that's not
quite the same as having the diffs inline. Y
also sprach Carl Worth [2010.02.04.1605 +1300]:
> > maint/? the stable release
> > master/ ? the stablising head
> > next/ ? testing branch
> > pu/ ? patch integration branch (proposed updates)
>
> I'm not a fan of this scheme, (or maybe I've just never quite understood
>
also sprach David Bremner [2010.02.04.0924 +1300]:
> > PS: speaking of prefixes, how about remving the subject prefix of
> > this list in general? ;)
>
> I used to agree, but in notmuch, I actually find it convenient to have
> threads marked by mailing list. Perhaps this will change if/when my
>
also sprach Marten Veldthuis [2010.02.04.0353 +1300]:
> > Like this? http://notmuchmail.org/recentchanges/
>
> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki
To my knowledge, neither of these two give you diffs. This is what
a post-receive hook offers.
It's trivial to do with G
On 4 February 2010 00:05, martin f krafft wrote:
> also sprach Servilio Afre Puentes [2010.02.04.1714
> +1300]:
>> In the second link, the links with the text "commitdiff" provide
>> it, and you have the Atom and RSS feeds at the bottom.
>
> As I see it, the feeds have links to the commitdiffs,
On 3 February 2010 15:18, martin f krafft wrote:
> also sprach Marten Veldthuis [2010.02.04.0353
> +1300]:
>> > Like this? http://notmuchmail.org/recentchanges/
>>
>> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki
>
> To my knowledge, neither of these two give you diffs. This is
On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth wrote:
> I want to maintain a branch myself, (where I'm the only person pushing
> to the branch). [This is different than what I've done with the cairo
> repository where we have all core maintainer's pushing to a central
> repository. I'm intentional
also sprach Servilio Afre Puentes [2010.02.04.1918 +1300]:
> > If there is indeed an RSS/Atom feed on gitweb that includes the
> > diffs inline, please give me the URL; I can't fine ond.
>
> Can't see that even in the code.
Carl, could you set up notmuch-comm...@notmuchmail.org and enable
the co
On 4 February 2010 00:05, martin f krafft wrote:
> also sprach Servilio Afre Puentes [2010.02.04.1714
> +1300]:
>> In the second link, the links with the text "commitdiff" provide
>> it, and you have the Atom and RSS feeds at the bottom.
>
> As I see it, the feeds have links to the commitdiffs,
also sprach Servilio Afre Puentes [2010.02.04.1714 +1300]:
> In the second link, the links with the text "commitdiff" provide
> it, and you have the Atom and RSS feeds at the bottom.
As I see it, the feeds have links to the commitdiffs, but that's not
quite the same as having the diffs inline. Yo
On 3 February 2010 15:18, martin f krafft wrote:
> also sprach Marten Veldthuis [2010.02.04.0353 +1300]:
>> > Like this? http://notmuchmail.org/recentchanges/
>>
>> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki
>
> To my knowledge, neither of these two give you diffs. This is wh
On Wed, 03 Feb 2010 19:05:42 -0800, Carl Worth wrote:
> I want to maintain a branch myself, (where I'm the only person pushing
> to the branch). [This is different than what I've done with the cairo
> repository where we have all core maintainer's pushing to a central
> repository. I'm intentional
also sprach Carl Worth [2010.02.04.1605 +1300]:
> > maint/— the stable release
> > master/ — the stablising head
> > next/ — testing branch
> > pu/ — patch integration branch (proposed updates)
>
> I'm not a fan of this scheme, (or maybe I've just never quite understood
>
On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft wrote:
> I discussed this with Carl at LCA a bit and ideally we should come
> up with a way to relieve Carl of the bottleneck burden (obviously
> without stealing away his dictator hat ;)
Sounds great! Let's keep working together and find ways t
On Tue, 26 Jan 2010 10:32:31 +1300, martin f krafft
wrote:
> I discussed this with Carl at LCA a bit and ideally we should come
> up with a way to relieve Carl of the bottleneck burden (obviously
> without stealing away his dictator hat ;)
Sounds great! Let's keep working together and find ways
On Thu, 4 Feb 2010 09:18:29 +1300, martin f krafft
wrote:
> PS: speaking of prefixes, how about remving the subject prefix of
> this list in general? ;)
I used to agree, but in notmuch, I actually find it convenient to have
threads marked by mailing list. Perhaps this will change if/when my
ema
also sprach David Bremner [2010.02.04.0924 +1300]:
> > PS: speaking of prefixes, how about remving the subject prefix of
> > this list in general? ;)
>
> I used to agree, but in notmuch, I actually find it convenient to have
> threads marked by mailing list. Perhaps this will change if/when my
>
On Thu, 4 Feb 2010 09:18:29 +1300, martin f krafft wrote:
> PS: speaking of prefixes, how about remving the subject prefix of
> this list in general? ;)
I used to agree, but in notmuch, I actually find it convenient to have
threads marked by mailing list. Perhaps this will change if/when my
emai
also sprach Marten Veldthuis [2010.02.04.0353 +1300]:
> > Like this? http://notmuchmail.org/recentchanges/
>
> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki
To my knowledge, neither of these two give you diffs. This is what
a post-receive hook offers.
It's trivial to do with G
also sprach micah anderson [2010.01.27.1124 +1300]:
> Couldn't all of this be done without moving the existing git
> repository (don't forget that transition is a cost)? Those who
> wish to put together these proposed branches go ahead and do so,
> publishing those wherever they like (git.debian.o
* martin f krafft (madduck at madduck.net) wrote:
> also sprach micah anderson [2010.01.27.1124 +1300]:
> > Personally, I've found mailing lists that have patches sent to
> > them tends to totally kill the list for anything else. It seems
> > a bit weird to use Debian's bug tracker for a non-Debia
* martin f krafft (madd...@madduck.net) wrote:
> also sprach micah anderson [2010.01.27.1124 +1300]:
> > Personally, I've found mailing lists that have patches sent to
> > them tends to totally kill the list for anything else. It seems
> > a bit weird to use Debian's bug tracker for a non-Debian n
On Wed, 27 Jan 2010 11:24:15 +1300, micah anderson wrote:
> Couldn't all of this be done without moving the existing git repository
> (don't forget that transition is a cost)? Those who wish to put together
> these proposed branches go ahead and do so, publishing those wherever
> they like (git.de
Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010:
> On Mon, 25 Jan 2010 16:46:43 -0800, sebastian at sspaeth.de wrote:
> > > I think it would make sense to move the mainline to git.debian.org
> > > for now, or another place where everyone can easily get an account.
> > > As
also sprach micah anderson [2010.01.27.1124 +1300]:
> Couldn't all of this be done without moving the existing git
> repository (don't forget that transition is a cost)? Those who
> wish to put together these proposed branches go ahead and do so,
> publishing those wherever they like (git.debian.o
On Mon, 25 Jan 2010 16:46:43 -0800, sebastian at sspaeth.de wrote:
> > I think it would make sense to move the mainline to git.debian.org
> > for now, or another place where everyone can easily get an account.
> > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > commercial ser
On Wed, 27 Jan 2010 11:24:15 +1300, micah anderson wrote:
> Couldn't all of this be done without moving the existing git repository
> (don't forget that transition is a cost)? Those who wish to put together
> these proposed branches go ahead and do so, publishing those wherever
> they like (git.de
Excerpts from micah anderson's message of Tue Jan 26 17:24:15 -0500 2010:
> On Mon, 25 Jan 2010 16:46:43 -0800, sebast...@sspaeth.de wrote:
> > > I think it would make sense to move the mainline to git.debian.org
> > > for now, or another place where everyone can easily get an account.
> > > As alt
On Mon, 25 Jan 2010 16:46:43 -0800, sebast...@sspaeth.de wrote:
> > I think it would make sense to move the mainline to git.debian.org
> > for now, or another place where everyone can easily get an account.
> > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > commercial servic
On Mon, 25 Jan 2010 14:49:00 +0100, "Sebastian Spaeth" wrote:
> While notmuchsync fullfils my needs, it is a kludge. It needs to call
> "notmuch" for each mail where a MailDir flag has changed (which can be
> quite often on an initial run, where most mails are likely to be read),
> this can take a
On Mon, 25 Jan 2010 14:49:00 +0100, "Sebastian Spaeth"
wrote:
> While notmuchsync fullfils my needs, it is a kludge. It needs to call
> "notmuch" for each mail where a MailDir flag has changed (which can be
> quite often on an initial run, where most mails are likely to be read),
> this can take
1 - 100 of 126 matches
Mail list logo
