On Fri, Apr 10, 2009 at 13:54, Sverre Rabbelier <srabbelier@xxxxxxxxx> wrote:
> On Fri, Apr 10, 2009 at 20:50, Michael Witten <mfwitten@xxxxxxxxx> wrote:
>> 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.
--
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