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.

> 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.

So there are some git tips that might be useful.

> Thanks.

You're quite welcome. Thanks for all the great work. Please keep it up!

-Carl

-- 
carl.d.worth@intel.com