threads / discuss / 18358

Ability to edit message from git rebase --interactive.

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

## tl;dr

16 messages between Mar 17, 2009 and Apr 10, 2009.

replies: 15people: 9as markdown or json

Olivier Goffart· Mar 17, 2009, 18:53 UTC · lore
Hello.

I use git in a workflow in wich we often need to edit the message logs of some commits. The way we do it is using git rebase -i and choose edit. But then you need to do git commit --amend and git rebase --continue, which is error prone and add more useless steps.

The attached patch add a new keyword to git rebase interactive to just edit the message log.

I was told on IRC that this has been discussed already not so long ago, and looking on the archive[1], all i seen was bikesheeding . Here is a patch :-)

Do you think it make sens to have that in git?
Please CC me replies.
-- 
Olivier


[1] http://thread.gmane.org/gmane.comp.version-control.git/105738
(my patch is different from this one as it adds a new keyword rather than 
change the behavior of one existing one)



commit 71793acdd9f926ea52d034b17ac3465e3a810799
Author: Olivier Goffart <ogoffart@kde.org>
Date:   Tue Mar 17 19:41:40 2009 +0100

    rebase interactive: add the possibility to easily edit the message log of commits

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3dc659d..6ded58e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -406,6 +406,16 @@ do_next () {
 			die_with_patch $sha1 ""
 		fi
 		;;
+	message|m)
+		comment_for_reflog message
+
+		mark_action_done
+
+		pick_one $sha1 ||
+			die_with_patch $sha1 "Could not apply $sha1... $rest"
+
+		git commit --amend || failed=t
+		;;
 	*)
 		warn "Unknown command: $command $sha1 $rest"
 		die_with_patch $sha1 "Please fix this in the file $TODO."
@@ -730,6 +740,7 @@ first and then run 'git rebase --continue' again."
 #  p, pick = use commit
 #  e, edit = use commit, but stop for amending
 #  s, squash = use commit, but meld into previous commit
+#  m, message = use commit and promt the editor to edit the message log
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 # However, if you remove everything, the rebase will be aborted.
Johannes Schindelin· Mar 17, 2009, 22:31 UTC · re: Olivier Goffart · lore

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

Hi,
On Tue, 17 Mar 2009, Olivier Goffart wrote:
Show 11 quoted lines
> I use git in a workflow in wich we often need to edit the message logs 
> of some commits. The way we do it is using git rebase -i and choose 
> edit.  But then you need to do git commit --amend and git rebase 
> --continue, which is error prone and add more useless steps.
> 
> The attached patch add a new keyword to git rebase interactive to just 
> edit the message log.
> 
> I was told on IRC that this has been discussed already not so long ago, 
> and looking on the archive[1], all i seen was bikesheeding .  Here is a 
> patch :-)

Unfortunately, the implementation is not the problem, but picking the best name. The first letter "m" will be taken in a short while by the "merge" command for "rebase -i -p", so "message" is out, sadly.

But the "rephrase" command will be part of the "rebase -i -p" series when I will finally be able to submit it.

Ciao, Dscho

Jeff King· Mar 18, 2009, 00:40 UTC · re: Johannes Schindelin · lore

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

On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
Show 10 quoted lines
> > I was told on IRC that this has been discussed already not so long ago, 
> > and looking on the archive[1], all i seen was bikesheeding .  Here is a 
> > patch :-)
> 
> Unfortunately, the implementation is not the problem, but picking the best 
> name.  The first letter "m" will be taken in a short while by the "merge" 
> command for "rebase -i -p", so "message" is out, sadly.
> 
> But the "rephrase" command will be part of the "rebase -i -p" series when 
> I will finally be able to submit it.

Also, I thought the general plan was to add such features to the git-sequencer work which will (hopefully) eventually replace "rebase -i". Dscho, can you give a brief update on how that is coming? Are rebase patches worth thinking about?

-Peff
Johannes Schindelin· Mar 18, 2009, 00:58 UTC · re: Jeff King · lore

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

Hi,
On Tue, 17 Mar 2009, Jeff King wrote:
Show 17 quoted lines
> On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
> 
> > > I was told on IRC that this has been discussed already not so long ago, 
> > > and looking on the archive[1], all i seen was bikesheeding .  Here is a 
> > > patch :-)
> > 
> > Unfortunately, the implementation is not the problem, but picking the best 
> > name.  The first letter "m" will be taken in a short while by the "merge" 
> > command for "rebase -i -p", so "message" is out, sadly.
> > 
> > But the "rephrase" command will be part of the "rebase -i -p" series when 
> > I will finally be able to submit it.
> 
> Also, I thought the general plan was to add such features to the
> git-sequencer work which will (hopefully) eventually replace "rebase
> -i". Dscho, can you give a brief update on how that is coming? Are
> rebase patches worth thinking about?

IMHO rebase -i is the important part. The user interface needs some serious overhaul, which I am in the slow process of doing. The sequencer then has to follow suit.

As it stands, I think sequencer is not good enough yet to replace rebase -i (all my comments about that are public, except the heads-up I sent Stephan in private).

To be frank, 'rebase -i -p' support, as it is in git.git is not good enough at all. That's why I was working on that, and I am close to finishing it.

Ciao, Dscho

Junio C Hamano· Mar 18, 2009, 01:06 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 17 quoted lines
> On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
>
>> > I was told on IRC that this has been discussed already not so long ago, 
>> > and looking on the archive[1], all i seen was bikesheeding .  Here is a 
>> > patch :-)
>> 
>> Unfortunately, the implementation is not the problem, but picking the best 
>> name.  The first letter "m" will be taken in a short while by the "merge" 
>> command for "rebase -i -p", so "message" is out, sadly.
>> 
>> But the "rephrase" command will be part of the "rebase -i -p" series when 
>> I will finally be able to submit it.
>
> Also, I thought the general plan was to add such features to the
> git-sequencer work which will (hopefully) eventually replace "rebase
> -i". Dscho, can you give a brief update on how that is coming? Are
> rebase patches worth thinking about?

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?

Sverre Rabbelier· Mar 18, 2009, 05:42 UTC · re: Junio C Hamano · lore

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

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...
-- 
Cheers,

Sverre Rabbelier
Michael J Gruber· Mar 18, 2009, 09:54 UTC · re: Sverre Rabbelier · lore

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

Sverre Rabbelier venit, vidit, dixit 18.03.2009 06:42:
Show 10 quoted lines
> 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.
Michael
Marcel M. Cary· Mar 18, 2009, 14:52 UTC · re: Michael J Gruber · lore

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

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
Marcel M. Cary· Mar 18, 2009, 21:02 UTC · re: Marcel M. Cary · lore

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

Marcel M. Cary wrote:
Show 48 quoted lines
> 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.

Ok, so I guess you have to explicity tell filter-branch all the commits that reach the ones you want to rewrite so it will know to fixup their parents. Below is a rough way of doing that, but sometimes it will find too many commits, and it's rather slow, even on a git.git.

git-rephrase: #!/bin/sh

if [ -z "$EDITOR" ]; then
     export EDITOR=vim
fi
# Does change tags
refs=$(git for-each-ref --format='%(refname)' 'refs/heads/*' |
     while read ref; do
         # This is the slow part
         if git rev-list $ref | grep -q $(git rev-parse --verify $1); then
             echo $ref
         else
             echo ^$ref
         fi;
     done
)
parents=$(git rev-list --max-count=1 --parents $1 | {
     read hash parents
     for hash in $parents; do
         echo ^$hash
     done
})
git filter-branch --msg-filter "
     if [ \$GIT_COMMIT = $(git rev-parse $1) ]; then
         cat > tmp
         \$EDITOR tmp < $(tty) > $(tty) 2>&1
         cat tmp
     else
         cat
     fi
" $refs $parents
Olivier Goffart· Apr 10, 2009, 12:17 UTC · re: Johannes Schindelin · lore

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

Le Tirsdag 17 mars 2009, Johannes Schindelin a écrit :
Show 21 quoted lines
> Hi,
>
> On Tue, 17 Mar 2009, Olivier Goffart wrote:
> > I use git in a workflow in wich we often need to edit the message logs
> > of some commits. The way we do it is using git rebase -i and choose
> > edit.  But then you need to do git commit --amend and git rebase
> > --continue, which is error prone and add more useless steps.
> >
> > The attached patch add a new keyword to git rebase interactive to just
> > edit the message log.
> >
> > I was told on IRC that this has been discussed already not so long ago,
> > and looking on the archive[1], all i seen was bikesheeding .  Here is a
> > patch :-)
>
> Unfortunately, the implementation is not the problem, but picking the best
> name.  The first letter "m" will be taken in a short while by the "merge"
> command for "rebase -i -p", so "message" is out, sadly.
>
> But the "rephrase" command will be part of the "rebase -i -p" series when
> I will finally be able to submit it.

Hi, Sorry I'm late to reply :-)

I still think this feature to edit the message in git rebase -i is really usefull. So 'm' is really taken, what about 'r' for 'rephrase'?

or maybe 'rephrase' is something different?
Regards
-- 
Olivier


commit 5d784b748328c7bccfddab7edba5a9dcf70518b8
Author: Olivier Goffart <ogoffart@kde.org>
Date:   Tue Mar 17 19:41:40 2009 +0100

    rebase interactive: add the possibility to easily edit the message log of commits

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 314cd36..91714d6 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -406,6 +406,16 @@ do_next () {
 			die_with_patch $sha1 ""
 		fi
 		;;
+	rephrase|r)
+		comment_for_reflog message
+
+		mark_action_done
+
+		pick_one $sha1 ||
+			die_with_patch $sha1 "Could not apply $sha1... $rest"
+
+		git commit --amend || failed=t
+		;;
 	*)
 		warn "Unknown command: $command $sha1 $rest"
 		die_with_patch $sha1 "Please fix this in the file $TODO."
@@ -754,6 +764,7 @@ first and then run 'git rebase --continue' again."
 #  p, pick = use commit
 #  e, edit = use commit, but stop for amending
 #  s, squash = use commit, but meld into previous commit
+#  r, rephrase = use commit and promt the editor to edit the message log
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 # However, if you remove everything, the rebase will be aborted.
Michael Witten· Apr 10, 2009, 12:37 UTC · re: Olivier Goffart · lore

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

On Fri, Apr 10, 2009 at 07:17, Olivier Goffart <ogoffart@kde.org> wrote:
Show 7 quoted lines
> Hi,
> Sorry I'm late to reply :-)
>
> I still think this feature to edit the message in git rebase -i is really
> usefull.  So 'm' is really taken, what about 'r' for 'rephrase'?
>
> or maybe 'rephrase' is something different?
How about 'a' for an immediate [a]mend?
Michael Witten· Apr 10, 2009, 12:41 UTC · re: Michael Witten · lore

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

On Fri, Apr 10, 2009 at 07:37, Michael Witten <mfwitten@gmail.com> wrote:
> How about 'a' for an immediate [a]mend?

However, rebase still seems overkill for most situations. I'd bet that usually people want to amend just 1 or 2 commit messages. Perhaps git-commit's --amend could take optional arguments and then run rebase appropriately behind the scene.

Johannes Schindelin· Apr 10, 2009, 18:21 UTC · re: Michael Witten · lore

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

Hi,
On Fri, 10 Apr 2009, Michael Witten wrote:
Show 10 quoted lines
> On Fri, Apr 10, 2009 at 07:17, Olivier Goffart <ogoffart@kde.org> wrote:
> > Hi,
> > Sorry I'm late to reply :-)
> >
> > I still think this feature to edit the message in git rebase -i is really
> > usefull.  So 'm' is really taken, what about 'r' for 'rephrase'?
> >
> > or maybe 'rephrase' is something different?
> 
> How about 'a' for an immediate [a]mend?

git commit --amend lets you amend the modifications in addition to the message, so I think it would be too ambiguous.

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

However, this will have to wait until after Easter.

Ciao, Dscho

Michael Witten· Apr 10, 2009, 18:50 UTC · re: Johannes Schindelin · lore

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

On Fri, Apr 10, 2009 at 13:21, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 9 quoted lines
>>> I still think this feature to edit the message in git rebase -i is really
>>> usefull. =A0So 'm' is really taken, what about 'r' for 'rephrase'?
>>>
>>> or maybe 'rephrase' is something different?
>>
>> How about 'a' for an immediate [a]mend?
>
> git commit --amend lets you amend the modifications in addition to the
> message, so I think it would be too ambiguous.
How about edit-message|edit-m|em ?
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.
How about:
    git commit --amend-message ...
for just the commit message?
P.S.
Sorry for the duplicate, Johannes.
Sverre Rabbelier· Apr 10, 2009, 18:54 UTC · re: Michael Witten · lore

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

Heya,
On Fri, Apr 10, 2009 at 20:50, Michael Witten <mfwitten@gmail.com> wrote:
Show 5 quoted lines
> 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?"

-- 
Cheers,

Sverre Rabbelier
Michael Witten· Apr 10, 2009, 19:04 UTC · re: Sverre Rabbelier · lore

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

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

← back to recent threads