From: David Bremner <david@tethera.net>
To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
In-Reply-To: <87ock3cf8j.fsf@yoom.home.cworth.org>
References: <87zl60xjl7.wl%bremner@pivot.cs.unb.ca>
	<87my1z97un.wl%bremner@pivot.cs.unb.ca>
	<87ock3cf8j.fsf@yoom.home.cworth.org>
Date: Sat, 06 Feb 2010 19:38:03 -0400
Message-ID: <87iqaaue90.fsf@rocinante.cs.unb.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] hack to retag a directory
Precedence: list

On Fri, 05 Feb 2010 17:41:48 -0800, Carl Worth <cworth@cworth.org> wrote:

[talking about gitmuch, a simple wrapper around notmuch dump && git commit]
> 
> And it's interesting that this script might be just good enough for the
> synchronization needs of some people. It's not integrated, and might
> require manual fixup of any resulting git conflicts, but it might be
> handy for some.
> 

I have to say that merge conflicts are not very much fun. I tend to do a
certain amount of oh, take all the changes from the server.  I wonder if
the approach that someone else mentioned of keeping a file
tags/message-id with the appropriate tags in it might make merging less
painful.

> The biggest problem I see is that if I were to read some messages
> locally, and then run "gitmuch restore" then this would wipe out the
> local changes I had made. So we'll definitely want a more integrated
> solution to eliminate the chance of problems like this.

Yeah, the footgun potential is definitely there.

> One easy answer is to just make "notmuch restore" do nothing for
> messages where the existing tags are the same as the tags mentioned in
> the input file. I just pushed a change to implement this, (along with
> new tests for "notmuch dump" and "notmuch restore" of course).

Heh, I think I later posted a patch to do that as well.

d