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

[Dan McGee]

On Sun, Feb 22, 2009 at 9:44 PM, Bryan Ischo
<bji-keyword-pacman.3644cb at www.ischo.com> wrote:
> 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.

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