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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html