On Sun, Feb 22, 2009 at 9:44 PM, Bryan Ischo <bji-keyword-pacman.3644cb@www.ischo.com> wrote:
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.
Completely false though! rebase -i lets you do a ton of things: If I'm presented with this when running "git rebase -i master": pick 42bb511 Add support for sleep command pick f1d477b Fix setting of low volume levels pick b3598cd Update comment pick 0f37e11 Add ability to control sleep timer from the frontend pick b3b64c7 Add concept of epoch to frontend pick 6285fc2 Don't record last sent time # Rebase d189b6a..6285fc2 onto d189b6a # # Commands: # p, pick = use commit # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. # I can do something like this (note the reordering and the command switching): pick 0f37e11 Add ability to control sleep timer from the frontend squash 42bb511 Add support for sleep command pick f1d477b Fix setting of low volume levels edit b3b64c7 Add concept of epoch to frontend pick 6285fc2 Don't record last sent time squash b3598cd Update comment And I'll end up with four new patches, ready to do whatever with. Multiple patch or single patch, it doesn't matter. I never use git-merge when doing my own work, btw- I'm really not sure that makes workflow easy at all, as I tend to cherrypick things around on multiple working branches if I want to move patches. -Dan