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