Dan McGee wrote:
On Sun, Feb 22, 2009 at 9:35 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
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.
Exactly what I was trying to get across.
The power that 'rebase -i' + squash gives you makes this _so_ easy.
-Dan _____
The wrinkle that makes things more complicated is that I was required to make my changes into three separate patches. So I have to maintain those changes as separate patches, and the --squash doesn't really help me. It's keeping the patches separate, while incorporating list feedback into each patch individually, that is hard to manage. Bryan