DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:to:subject:in-reply-to:references:user-agent:date:message-id
	:mime-version:content-type;
	b=OSnKQfMsIkkrU4Twm33R9oK54L6pLnKSZ4IbOS+35Qj59xdnADu5VipkvwDFqWtQqT
	5WUydiNGPyUbU3AMZJPNIdN7Hk5vAsycsrdMatoyzL0SyHyfXFb0pTIkv2eTeTxumels
	EZwlOuBXxqLufONWwpGhc7eyphVO3MVzCAAXU=
From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
Subject: Re: [PATCH 3/5] Fix hiding a message while some citations are shown
	in notmuch-show view.
In-Reply-To: <87fwnbf2rv.fsf@yoom.home.cworth.org>
References: <1306361416-5019-1-git-send-email-dmitry.kurochkin@gmail.com>
	<1306361416-5019-4-git-send-email-dmitry.kurochkin@gmail.com>
	<87oc2qa07g.fsf@yoom.home.cworth.org> <87k4depfyj.fsf@gmail.com>
	<87lixu9z5b.fsf@yoom.home.cworth.org> <87hb8ipeb0.fsf@gmail.com>
	<87ipsy9sue.fsf@yoom.home.cworth.org> <87d3j5pxk5.fsf@gmail.com>
	<87k4ddcfnx.fsf@yoom.home.cworth.org> <877h9dp29t.fsf@gmail.com>
	<87sjrbkx3j.fsf@yoom.home.cworth.org> <8739jbqiid.fsf@gmail.com>
	<87fwnbf2rv.fsf@yoom.home.cworth.org>
User-Agent: Notmuch/0.5-237-gf6d8cdb (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Wed, 15 Jun 2011 21:10:49 +0400
Message-ID: <87sjrb10me.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 15 Jun 2011 10:00:36 -0700, Carl Worth <cworth@cworth.org> wrote:
> On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> > I know you prefer tests to go before patches and I agree with that.
> 
> Great!
> 
> > But most of the time I do tests after coding.
> 
> Yes, I do that order almost exclusively as well.
> 
> > I do not know an easy way to reorder patches in git.  (Also I do not
> > know how to amend an old patch
> 
> Fortunately, git has a great feature here for both use cases, (git
> rebase -i). Here's the simple recipe:
> 
>     * Find a bug, fix a bug, commit
> 
>     * Write a test case, commit
> 
>     * Run the following command:
> 
> 	git rebase -i origin/master
> 
> At this point you'll be presented with an editor window giving one line
> for each commit that you have made since origin/master. You can reorder
> these lines however you'd like. When you save and exit the editor, the
> commits will be applied in the order you saved.
> 
> If there are any conflicts due to the re-ordering, then git rebase will
> stop and tell you what to do, which will be:
> 
>     * Resolve the conflict
> 
>     * Run "git add" on the files you edited
> 
>     * Run "git rebase --continue"
> 
> Also, back when editing the original list of commits, you can change the
> word "apply" next to any particular commit to change what happens when
> applying it. If you change that to "reword" you'll be given an editor
> window to edit the commit message. If you use "edit" then you'll be
> dropped to a shell where you can:
> 
>     * Edit the code
> 
>     * Test as necessary
> 
>     * Run "git commit --amend"
> 
>     * Run "git rebase --continue"
> 
> I absolutely love "git rebase -i". It's one of my favorite
> user-interface features in git.
> 

Thanks for this.  I did not know about interactive mode in rebase.

This is some sort of replacement for darcs amend (which allows editing
any patch, not just the last one).

> > wish more darcs features in git.
> 
> I don't know about "git rebase -i", but I think I heard that "git add
> -i", (interactively add some portions of the dirty working tree to the
> index to be committed). I think the menu-based interface of "git add -i"
> is particularly clunky. But I love the trimmed-down interface of "git
> add -p" which simply prompts one-patch-hunk-at-a-time for pieces to add
> to the next commit. It even supports splitting a hunk, (or even manually
> editing the patch to trim it down!). It's pretty slick stuff.
> 

Yes, "add -i" is ugl... confusing, but "add -p" is very nice.  A great
feature of darcs picked up by git.

> So there are some git tips that might be useful.
> 

They will be useful indeed.  Thanks!

Regards,
  Dmitry

> > Thanks.
> 
> You're quite welcome. Thanks for all the great work. Please keep it up!
> 
> -Carl
> 
> -- 
> carl.d.worth@intel.com