# Ability to edit message from git rebase --interactive. 16 messages from 2009-03-17 to 2009-04-10. Participants: Olivier Goffart, Johannes Schindelin, Jeff King, Junio C Hamano, Sverre Rabbelier, Michael J Gruber, Marcel M. Cary, Michael Witten. Thread: https://gitlist.dev/t/18358 ## Olivier Goffart, 2009-03-17 18:53 Subject: Ability to edit message from git rebase --interactive. Message-ID: <200903171953.23650.ogoffart@kde.org> URL: https://gitlist.dev/e/200903171953.23650.ogoffart%40kde.org ``` 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 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, 2009-03-17 22:31 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0903172329480.10279%40pacific.mpi-cbg.de In-Reply-To: <200903171953.23650.ogoffart@kde.org> ``` 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 ``` ## Jeff King, 2009-03-18 00:40 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: <20090318004056.GB25454@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090318004056.GB25454%40coredump.intra.peff.net In-Reply-To: ``` 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 ``` ## Johannes Schindelin, 2009-03-18 00:58 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0903180155270.10279%40pacific.mpi-cbg.de In-Reply-To: <20090318004056.GB25454@coredump.intra.peff.net> ``` 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 ``` ## Junio C Hamano, 2009-03-18 01:06 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: <7vsklbod0l.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsklbod0l.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20090318004056.GB25454@coredump.intra.peff.net> ``` Jeff King 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? ``` ## Sverre Rabbelier, 2009-03-18 05:42 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/fabb9a1e0903172242v6f67aa9er40fe0ae2a2db7bc3%40mail.gmail.com In-Reply-To: <7vsklbod0l.fsf@gitster.siamese.dyndns.org> ``` Heya, On Wed, Mar 18, 2009 at 02:06, Junio C Hamano wrote: > Jeff King 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, 2009-03-18 09:54 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: <49C0C4C5.5070802@drmicha.warpmail.net> URL: https://gitlist.dev/e/49C0C4C5.5070802%40drmicha.warpmail.net In-Reply-To: ``` Sverre Rabbelier venit, vidit, dixit 18.03.2009 06:42: > Heya, > > On Wed, Mar 18, 2009 at 02:06, Junio C Hamano wrote: >> Jeff King 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, 2009-03-18 14:52 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: <49C10A97.6060201@oak.homeunix.org> URL: https://gitlist.dev/e/49C10A97.6060201%40oak.homeunix.org In-Reply-To: <49C0C4C5.5070802@drmicha.warpmail.net> ``` 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 wrote: >>> Jeff King 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, 2009-03-18 21:02 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: <49C16150.6070001@earth.care2.com> URL: https://gitlist.dev/e/49C16150.6070001%40earth.care2.com In-Reply-To: <49C10A97.6060201@oak.homeunix.org> ``` 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 wrote: >>>> Jeff King 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, 2009-04-10 12:17 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: <200904101417.56422.ogoffart@kde.org> URL: https://gitlist.dev/e/200904101417.56422.ogoffart%40kde.org In-Reply-To: ``` 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 commit 5d784b748328c7bccfddab7edba5a9dcf70518b8 Author: Olivier Goffart 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, 2009-04-10 12:37 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/b4087cc50904100537j64e8fef1u157c717fe4d8207b%40mail.gmail.com In-Reply-To: <200904101417.56422.ogoffart@kde.org> ``` On Fri, Apr 10, 2009 at 07:17, Olivier Goffart 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? ``` ## Michael Witten, 2009-04-10 12:41 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/b4087cc50904100541h2dfb0902jf38f3254394afad0%40mail.gmail.com In-Reply-To: ``` On Fri, Apr 10, 2009 at 07:37, Michael Witten 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, 2009-04-10 18:21 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0904102019250.10279%40pacific.mpi-cbg.de In-Reply-To: ``` Hi, On Fri, 10 Apr 2009, Michael Witten wrote: > On Fri, Apr 10, 2009 at 07:17, Olivier Goffart 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, 2009-04-10 18:50 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/b4087cc50904101150i31f1bbfdre73bec44dac580eb%40mail.gmail.com In-Reply-To: ``` On Fri, Apr 10, 2009 at 13:21, Johannes Schindelin 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. ``` ## Sverre Rabbelier, 2009-04-10 18:54 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/fabb9a1e0904101154o6b4759ddk879bcdabcc03add6%40mail.gmail.com In-Reply-To: ``` Heya, On Fri, Apr 10, 2009 at 20:50, Michael Witten 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 ``` ## Michael Witten, 2009-04-10 19:04 Subject: Re: Ability to edit message from git rebase --interactive. Message-ID: URL: https://gitlist.dev/e/b4087cc50904101204l783acb9lb40b7abfc8573a62%40mail.gmail.com In-Reply-To: ``` On Fri, Apr 10, 2009 at 13:54, Sverre Rabbelier wrote: > On Fri, Apr 10, 2009 at 20:50, Michael Witten 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. ```