[PATCH 3/5] Fix hiding a message while some citations are shown in notmuch-show view.

[Dmitry Kurochkin]

On Wed, 15 Jun 2011 10:00:36 -0700, Carl Worth <cworth at cworth.org> wrote:
> On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin <dmitry.kurochkin at 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 at intel.com