From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 6A055429E33 for ; Fri, 6 Jan 2012 00:27:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9AQd8wTXhfi for ; Fri, 6 Jan 2012 00:27:26 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 74F4C429E32 for ; Fri, 6 Jan 2012 00:27:26 -0800 (PST) Received: by werm12 with SMTP id m12so1121267wer.26 for ; Fri, 06 Jan 2012 00:27:23 -0800 (PST) Received: by 10.216.131.141 with SMTP id m13mr2657354wei.30.1325838443696; Fri, 06 Jan 2012 00:27:23 -0800 (PST) Received: from hotblack-desiato.hh.sledj.net (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25]) by mx.google.com with ESMTPS id em4sm67411213wbb.20.2012.01.06.00.27.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 00:27:21 -0800 (PST) Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000) id 5E091A1734; Fri, 6 Jan 2012 08:27:19 +0000 (GMT) To: David Bremner , notmuch@notmuchmail.org Subject: Re: [PATCH] emacs: Helpers for notmuch developers. In-Reply-To: <878vllxzwt.fsf@zancas.localnet> References: <1325685678-12710-1-git-send-email-dme@dme.org> <878vllxzwt.fsf@zancas.localnet> User-Agent: Notmuch/0.10.2+151~gbf1dc2b (http://notmuchmail.org) Emacs/24.0.92.1 (x86_64-pc-linux-gnu) From: David Edmondson Date: Fri, 06 Jan 2012 08:27:15 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:27:27 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 05 Jan 2012 23:39:30 -0400, David Bremner wrote: > > General management (i.e. keeping up to date) of the repository it uses > > is your responsibility, as is cleaning out old branches. You can, of > > course, just delete the temporary repository after using it - the code > > will re-create it next time. >=20 > maybe the branches could be under some namespace that makes this easy? Just a prefix? 'review/' or something? > > +(defvar notmuch-dev-temporary-repository-name (concat "notmuch-dev-" (= user-login-name)) > > + "The name of the temporary repository.") >=20 > Do we care about security at all in this context? I'm always a bit > nervous about creating predictably named files/directories in publicly > writable places. I presume that you'd already have set `temporary-file-directory' if you worry about this generally, or `notmuch-dev-temporary-directory' if just in this instance. > > + ;; Causes us to switch to the magit buffer - is that unfortunate in > > + ;; some situations? > > + (magit-status notmuch-dev-temporary-repository-path)) >=20 > I found it to be a pleasant surprise. Ending there when the whole sequence completes, I agree. The question is really about whether displaying the magit-status buffer after simply creating the repository is good. > > + (shell-command > > + (concat > > + notmuch-command " show --format=3Dmbox " (shell-quote-argument search= -terms) > > + " | " > > + "git am --quiet")) > > + >=20 > Hmm. A knee jerk reaction is not to like this, like seeing system in C > code. But I don't have a better solution off hand. Agreed. I think that I'll split it into two parts: - running notmuch to create a mailbox (or perhaps directory of patches), - running git-am to apply the patches. A bigger problem is that magit appears to be ignorant of git-am, with the result that if applying the patches fails magit doesn't provide any help (or even notification) that there are outstanding things to do. It also blocks a future git-am. Currently thinking about an alternative to using git-am that is more magit friendly... --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8GsGMACgkQaezQq/BJZRaAqQCeLWxt7y5MAPU5Mnpkphg0co/G 1pcAn10Mk7G7H+DqL1RzuHmI4/teWxJ1 =Yns4 -----END PGP SIGNATURE----- --=-=-=--