Thread (11 messages) 11 messages, 5 authors, 2016-06-15

Re: Ability to edit message from git rebase --interactive.

flat view

From: Michael Witten <hidden>
Date: 2016-06-15 22:46:35

On Fri, Apr 10, 2009 at 13:54, Sverre Rabbelier [off-list ref] wrote:
On Fri, Apr 10, 2009 at 20:50, Michael Witten [off-list ref] wrote:
quoted
Also, I still like the idea of being able to write:

   git commit --amend HEAD~5 HEAD^

and then have the rebase setup and started for me.
Suggested before and shot down with "how would that work in the light
of merges?
I guess that depends on what Johannes Schindelin said:
FWIW I planned to split my rebase-i-p patch series into two parts: the first part adding a few commands, and the second part actually making it possible to rebase interactively _and_ preserving merges.  (So far, if you used -p, you better did not reorder or delete any lines.)
Unfortunately, I've never thought about it, so I don't fully
understand the implications. However, why should someone with a
simpler scenario have to suffer because of someone else's hypothetical
nightmare? ;-D

On a separate note:

To clarify, I was specifying two commits that I want to amend (HEAD~5
and HEAD^). For instance, this specifies 3 commits:

    git commit --amend HEAD~5 HEAD^ HEAD~10

However, I'm sure it would also be useful to allow ranges as well.
Should the dot notation (THIS..THAT) be reappropriated? I ask, because
it doesn't really mean range.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help