[RFC] teach --edit to git rebase

The idea of this patch is to allow a simple edition of a buggy commit in the history.

## Motivation

The motivation behind the option is that sometime I have to do a simple fixup of a previous commit. Usually the way to do it is just to commit the fix on the top of the branch (git commit --fixup) then doing a 'git rebase --autosquash'. However, the way is often not optimal if the context of commit on the top of the branch is different from the context of the buggy commit, thus the rebase with a fixup will lead to a conflict when git will apply the fixup patch to the buggy commit (and a second conflict later).

An other way is to do a 'git rebase --interactive' with an edit in the todo list (instead of a pick). This is what I propose to simplify.

## Proposal

My idea is to add a --edit option to 'git rebase' in order to automatize the 'git rebase --interactive' workflow.

Currently:

    $ git rebase -i commit-to-fix^
    # replace the first 'pick' with 'edit' then save and quit
    $ hack hack hack...
    $ git commit --amend  # or whatever you want to do like split commit
    $ git rebase --continue  # and resolve possible conflicts

With the --edit option:

    $ git rebase --edit commit_to_fix # note: no caret, no editor ! yeah !
    $ hack hack hack...
    $ git commit --amend  # or what ever like split commit
    $ git rebase --continue  # and resolve possible conflicts

Note that for a more complex history modification, a standard git rebase with reordering, squashing and stuff the way to go is a good old git rebase --interactive.

## Implementation proposal

Yes I know "show me the code" but because I am lazy I prefer ask 1-if the proposal makes sense, and 2-if the following way of doing it makes sense.

The idea is to extend git-rebase and git-rebase-interactive.

* detect and check the option --edit in git-rebase
* automatically prepare the todolist in git-rebase-interactive without
launching the editor.

## Alternative proposals

A weak point of the proposal it that it is a new option to a overloaded git command (git rebase). In fact is is even a new synopsis to git rebase since the --edit option will be incompatible with --interactive (it is an automatic interactive) and with --onto (since there is no real point to ``move'' the base if you want to fixup a single commit). A counter proposal could be to not extend the command 'git rebase' but add a new git command (for instance 'git edit buggy_commit') but since the edit may[1] lead to conflicts the user has to do some 'git edit --continue' to finish the editing (or 'git edit --abort' if bored). It will also require to adapt a lot of tinny things because hint messages, error messages, and prompts will talk about 'rebase' and not 'edit'.

[1] In fact, it is probable that the *may* is in fact a *will* since if no conflict arise, it is likable that a simple 'commit --fixup' (followed by a later 'git rebase --autosquash') will just work and be simpler.

An other alternative is to use a simple git alias for myself (and do not bother the git community) but I do not know how to automatize the command 'git rebase --interactive' I suppose I need more complex infrastructure in the existing 'git rebase' (Maybe I did not look enough and there is a way to do it with a git alias).

A last alternative is do do nothing. What I propose is just a way to 1-do not need a caret ('git rebase --edit commit' instead of 'git rebase --interactive commit^') and 2-avoid launching the editor. Therefore, maybe the itch do not really need a patch.

-- Jean Privat