[pacman-dev] [PATCH 1/2] Enabled new interactive prompt and updated some tests.

[Sebastian Nowicki]

On 23/02/2009, at 5:55 AM, Bryan Ischo wrote:

> To be honest, this isn't a whole lot better in terms of number of  
> git commands to run, or things to screw up, as my "create new  
> branch, merge changes in one at a time, fix, and recommit them"  
> process, but if it's the standard way, then I'll do it.
>
> The hard parts of getting all of the little details in the changes  
> right, and having to repeat the process if I make any mistakes, plus  
> rebulding, running tests, etc, between each change, all are still  
> required.

You're workflow seems overfly complicated. What I do is simply keep  
committing on top of the previous commits:

  - In my new branch I make the initial commit
  - I run `git format-patch HEAD^`, and send the patch off.
  - When I get feedback I make the changes and keep committing.
  - When it's time to submit again, I either make a new branch from  
merge and `git merge --squash my_branch` (this lets me keep the  
history on the other branch in case I need to revert), or simply `git  
rebase -i FIRST_COMMIT^` (where FIRST_COMMIT is the original commit  
for the branch) and squash the commits.
  - The last thing to do is `git format-patch` and send it off again.  
All very simple. I'm not sure that you'd find an SCM which makes this  
easier.

More briefly:

git checkout -b my_branch master
#edit
git commit -s -m "My awesome feature"
git format-patch HEAD^
git send-email --to foo at bar.org 0001*.patch
# Get feedback
# Edit
git commit -m "Fixed something"
# Edit
git commit -m "Fixed something else"
git checkout -b squash_my_branch master
git merge --squash my_branch
git commit -s
# Editing the commit message is somewhat annoying, rebase doesn't have  
this problem.
rm -f 0001*.patch
git format-patch HEAD^
git send-email --to foo at bar.org 0001*.patch