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

["Marcel M. Cary" <marcel@oak.homeunix.org>]

Michael J Gruber wrote:
> Sverre Rabbelier venit, vidit, dixit 18.03.2009 06:42:
>> Heya,
>>
>> On Wed, Mar 18, 2009 at 02:06, Junio C Hamano <gitster@pobox.com> wrote:
>>> Jeff King <peff@peff.net> writes:
>>> I am not quite sure what rephrase is buying us.  Do we also want to
>>> introduce retree that allows you to muck with the tree object recorded
>>> without giving you a chance to clobber the commit log message?
>> Is that a common operation? Rephrase is, at least to me...
>>
> 
> Rephrase for sure is common, and for sure can be done currently... It's
> only that "commit --amend, save&quit, continue" could be shortened.
> 
> OTOH: Most commonly one would want to rephrase a commit message or two
> without actually rebasing anything. And the proposed change doesn't help
> as much as it could, in two respects:
> 
> 1) I want to be able to say "rephrase HEAD~2" without having to edit a
> rebase action script. (That would be useful for rewriting a single
> commit as well, and could be added easily.)
> 
> 2) Currently, all rebasing operations have trouble with merges. But if
> all I want to do is rephrasing a log message then no diff/apply is
> necessary, no rewriting of trees, no change in the DAG structure (i.e.
> connectivity; sha1s change, of course). So there should be a special
> mode for DAG-preserving rewrites, where one can be sure that merges are
> fully preserved.
> 
> 2) seems to be the most important point to make rephrasing safe and
> convenient.

Interesting points about skipping the action script and preserving
structure.  I just tried to do something like that with filter-branch:

git filter-branch --msg-filter 'cat > tmp;  $EDITOR tmp < '$(tty)' >
'$(tty)' 2>&1; cat tmp' ^HEAD^ HEAD

And discovered that it will neither accept "HEAD^^..HEAD^" nor "HEAD^"
as a shortcut for a rev-list containing a single commit.  But if you're
content to save and quit each message through the branch tip and specify
the range, it seems to work.

I have no idea what it would take to make filter-branch support the
additional kinds of rev and rev list specifications, or if that would be
undesirable.

I'm assuming it accomplishes (2) because of the nature of filter-branch.

Marcel