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

From: Marcel M. Cary <marcel@oak.homeunix.org>
Date: Mar 18, 2009, 14:52 UTC
Message-ID: <49C10A97.6060201@oak.homeunix.org>
In-Reply-To: <49C0C4C5.5070802@drmicha.warpmail.net>

Michael J Gruber wrote:

Show 31 quoted lines

> 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