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

[Dan McGee]

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

Nope. You modify the branch you want to modify. I think that is where
you are making it harder on yourself than you need to, as you are
attempting to do work that git already does for you.

If you fuck something up, try typing 'git reflog show <branchname>'.
You will see every point that branch has been known as for at least
the last 30 days. If I screw something up, I can open up that reflog,
grab the partial sha1, and just do a "git reset --hard <sha1>" to
bring my branch back to that exact state.

-Dan