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

Bryan Ischo bji-keyword-pacman.3644cb at www.ischo.com
Sun Feb 22 22:57:21 EST 2009


Dan McGee wrote:
>> 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.
>   


OK, so I guess I really need to get into the habit of using git-rebase -i.

One question: I should do the rebase -i onto a new branch, right, so as 
not to disturb my existing branch?  Because if I make a mistake, I want 
to be able to recover by blowing away the branch I was rebasing into, 
and starting over with a new one.  Does that make sense?

Thanks,
Bryan



More information about the pacman-dev mailing list