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

[Bryan Ischo]

Dan McGee wrote:
> On Sun, Feb 22, 2009 at 9:35 PM, Sebastian Nowicki <sebnow at 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