Ability to edit message from git rebase --interactive.

Ability to edit message from git rebase --interactive.

[Olivier Goffart]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

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)


[-- Attachment #2: editmessage.diff --]
[-- Type: text/x-patch, Size: 1158 bytes --]

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.

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

[Johannes Schindelin]

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.

Ciao,
Dscho

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

[Jeff King]

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?

-Peff

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

[Johannes Schindelin]

Hi,

On Tue, 17 Mar 2009, Jeff King wrote:

> 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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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?

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

[Sverre Rabbelier]

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

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

[Michael J Gruber]

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.

Michael

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

[Marcel M. Cary]

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

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

[Marcel M. Cary]

Marcel M. Cary wrote:
> 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

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

[Olivier Goffart]

[-- Attachment #1.1: Type: text/plain, Size: 1269 bytes --]

Le Tirsdag 17 mars 2009, Johannes Schindelin a écrit :
> 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

[-- Attachment #1.2: rephrase.diff --]
[-- Type: text/x-diff, Size: 1160 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Michael Witten]

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?

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

[Michael Witten]

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.

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 879 bytes --]

Hi,

On Fri, 10 Apr 2009, Michael Witten wrote:

> 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

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

[Michael Witten]

On Fri, Apr 10, 2009 at 13:21, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>>> 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.

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

[Sverre Rabbelier]

Heya,

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?"

-- 
Cheers,

Sverre Rabbelier

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

[Michael Witten]

On Fri, Apr 10, 2009 at 13:54, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> 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.