> 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
--
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