Ability to edit message from git rebase --interactive.

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)

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

On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:

quoted

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

Hi,

On Tue, 17 Mar 2009, Jeff King wrote:

On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:

quoted

quoted

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

Le Tirsdag 17 mars 2009, Johannes Schindelin a écrit :

Hi,

On Tue, 17 Mar 2009, Olivier Goffart wrote:

quoted

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

On Fri, Apr 10, 2009 at 07:17, Olivier Goffart [off-list ref] 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?

On Fri, Apr 10, 2009 at 07:37, Michael Witten [off-list ref] 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.

Hi,

On Fri, 10 Apr 2009, Michael Witten wrote:

On Fri, Apr 10, 2009 at 07:17, Olivier Goffart [off-list ref] wrote:

quoted

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

On Fri, Apr 10, 2009 at 13:21, Johannes Schindelin
[off-list ref] wrote:

quoted

quoted

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.

Heya,

On Fri, Apr 10, 2009 at 20:50, Michael Witten [off-list ref] 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

On Fri, Apr 10, 2009 at 13:54, Sverre Rabbelier [off-list ref] wrote:

On Fri, Apr 10, 2009 at 20:50, Michael Witten [off-list ref] wrote:

quoted

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.