On Mon, May 31, 2010 at 19:37, Philip Jackson <[email protected]> wrote:
> At Mon, 31 May 2010 17:52:35 +0000,
> var Arnfj r Bjarmason wrote:
>>
>> On Mon, May 31, 2010 at 16:49, Philip Jackson <[email protected]>
>> wrote:
>> > I've just push rebase-mode (not requred in magit itself and not part
>> > of the deployment process). It's a mode for editing the
>> > git-rebase-todo file.
>> >
>> > Give it a try, if it's useless I'll get rid/improve it, otherwise
>> > perhaps magit could eventually load it.
>>
>> This is definitely useful. Doing rebases is pretty much the last thing
>> that I do in a non-Emacs fashion with Git. I sent you a minor patch
>> for it.
>
> Great, but where did you send it, I can't find it...
It was the one I sent you a pull request for, which you've already
integrated. Sorry for the noise.
>> Scary braindump follows:
>>
>> I don't like there not being "p" and "n" keys to move
>> back/forward. But I could see how moving "p" away from "pick" would be
>> really confusing. Nevertheless I'm using this customization for
>> myself:
>>
>> (define-key rebase-mode-map (kbd "i") 'rebase-mode-pick)
>> (define-key rebase-mode-map (kbd "p") 'previous-line)
>> (define-key rebase-mode-map (kbd "n") 'next-line)
>
> Yea, you're right, I hit n/p expecting it do move the cursor. Perhaps
> I'll bind pick to "c" for "commit"?
Anything non-p is probably going to be equally confusing. Personally I
always pick the next letter ("i" in this case) of the word. But color
the bike shed however you find appropriate :)
>> The highlighting colors in the mode appear seemingly at random. When I
>> start a new rebase for magit's master^^ I get highlighted entries on
>> the first line and later (seemingly at random) in the list. Moving
>> commits around at the top of the list moves the highlighting between
>> seemingly unrelated commits at the bottom.
>
> That sounds odd. I can't get it to do the same thing. If you figure
> out what's going on do let me know.
I'm running Emacs 23.1.1. Here's a video of it happening:
http://v.nix.is/~avar/magit-rebase-funky.mpeg
>> When I mark some commits for "edit" magit will stop at a detached head
>> as expected. However after I've amended/stashed more stuff, how do I
>> continue the rebase? I.e. git commit --amend && git rebase --continue?
>
> From Magit? You can't. Once this mode is working well we'll have to
> try and integrate the two better somehow. We need to parse the result
> of shell commands and act on them appropriately.
Ah neat. I was just wondering whether there was a skeleton
implementation of that that I'd missed somewhere.
>> When I press "E" in a running rebase it offers to start a new rebase
>> and then says "rebase already running". Is there any reason not to
>> just switch to the git-rebase-todo buffer here?
>
> I suppose if there's a git-rebase-todo buffer, for that project, it
> should switch.
\o/
>> It would also be nice if "Type C-c C-c to commit (C-c C-k to cancel)."
>> worked in the git-rebase-todo buffer.
>
> Agreed. I'll stick 'em in.
\o/
>> I'm not sure how, but I managed to make it cry by somehow killing the
>> git-rebase-todo buffer so that Git didn't have a chance to clean up
>> after itself. When I started a new rebase after that I got:
>>
>> $ git --no-pager rebase -i master^
>> Interactive rebase already started
>> Git exited abnormally with code 1.
>>
>> That needed a git rebase --abort in a shell to clean up.
>
> A conflict perhaps? You wouldn't be warned properly so might have
> missed it.
Yeah, probably.
> To be frank, the interactive rebase functionality
> (`magit-interactive-rebase') within magit has always been a little
> fragile. It's 'native' rebase (`magit-rewrite-*') tools are pretty
> solid though.
Yeah. I noticed that it's taking the concept of "porcelain" a little
too literally :) But I'll try to use it and submit patches. Aside from
choosing "edit" + "git add -u" + "git commit --amend" this covers
everything I do with "git rebase -i" already. Thanks.
