Re: [RFC] teach --edit to git rebase

From: Jean Privat <jean.privat@gmail.com>
Date: Oct 12, 2011, 13:57 UTC
Message-ID: <CAMQw0oOKsVv82c5yaHR0LQu+B-OaBAE8OBXQH-ksiQc2KEBnjA@mail.gmail.com>
In-Reply-To: <7vvcrubyz1.fsf@alter.siamese.dyndns.org>

> The only thing you can do with this new option is "update one commit
> buried in the history, and rebase everything that build on top of it",

It is a good summary indeed.

> as
> far as I can tell. It feels a shame to waste the generic word "--edit" for
> such a narrow option.

I'm bad at bikesheeding. The 'edit' come from the 'edit' command in rebase interactive. I am open to other names. Note that in the following I keep the --edit name, not because I am suborn but because I do not have better to propose yet.

> At the UI level, "git commit --amend HEAD~4" might be a more natural way
> to invoke such an operation, I would think.

As I say in the original email the point of the 'rebase --edit some-commit' is to temporally checkout some-commit so that edits are done in the context of the commit and not in the context of the head of the branch. One has to do a rebase --edit prior to modification (although we can imagine a possibility to bring back the index or the content of the working directory with us either automatically as with a branch checkout or manually with the help of stash).

Unless I misinterpret the 'git commit --amend HEAD~4' you suggest, it means that you have to prepare the commit in the head of the branch. It may be difficult if what was in HEAD~4 is altered by HEAD~2. My argument is that if preparing a patch to HEAD~4 in HEAD is easy, a git commit --fixup will do the tick. If the preparation is difficult because I have to work on (or more insidious, near) change that occurs between HEAD~4 and HEAD, I need something like my proposal. For example I added a line in HEAD~2 but I prefer now to have this line to appears in HEAD~4.

The workflow I propose is :

$ # we are on master
$ git rebase --edit HEAD~4 # workdir is a detached master~4 like with a
                           # git checkout master~4
$ hack hack hack; git add files
$ git commit --amend
$ git rebase --continue # conflict is detected with master~2, resolve it
                        # manually
$ git rebase --continue # workdir is now a rebased master

I do no see what is the workflow with an extend git commit --amend Do you mean something like the following ?

$ git checkout HEAD~4 -- . # bring back the content of master~4 but
                           # HEAD still points master
$ hack hack hack; git add files # And try to now be disturbed by the fact
                                # that diff and status are polluted
                                # with things related to master
$ git commit --amend HEAD~4 # conflict is detected with master~2, resolve it
$ git rebase --continue # Do we really want using "git rebase"?

This last workflow seems so awkward to me that I might miss something.

-- Jean Privat