[PATCH 1/1] Add support for an optional .nextmsg file to git-commit-script

[PATCH 1/1] Add support for an optional .nextmsg file to git-commit-script

[Jon Seymour]

This change allows a commit message to be prepared prior to git-commit-script being
invoked. During git commit the user is then given an opportunity to edit the
existing message, if any, and must confirm the commit by deleting a sentinel
line from the top of the edit buffer.

If the user does not delete the sentinel line, the commit is aborted and the
text of the message is saved for future editing.

The purpose of this change is to enable undo/redo tools to repopulate a commit
message from a previous commit that has been undone and then allow the user to
make small edits to the previous commit message prior recommitting the change.

If the .nextmsg file does not exist, git-commit-script behaves as before.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---

 git-commit-script |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -1,5 +1,12 @@
 #!/bin/sh
+SENTINEL="*** delete this line to confirm the commit ***"
 : ${GIT_DIR=.git}
+:> .editmsg
+
+if [ -f .nextmsg ]
+then
+    cat .nextmsg   >>.editmsg
+fi
 PARENTS="HEAD"
 if [ -f $GIT_DIR/MERGE_HEAD ]; then
 	echo "#"
@@ -9,17 +16,31 @@ if [ -f $GIT_DIR/MERGE_HEAD ]; then
 	echo "# and try again"
 	echo "#"
 	PARENTS="HEAD -p MERGE_HEAD"
-fi > .editmsg
+fi >> .editmsg
 git-status-script >> .editmsg
 if [ "$?" != "0" ]
 then
 	cat .editmsg
 	exit 1
 fi
+if [ -f .nextmsg ]
+then
+    echo "$SENTINEL" >>.editmsg
+fi
 ${VISUAL:-${EDITOR:-vi}} .editmsg
-grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
+if [ -f .nextmsg ]
+then
+    egrep -v "(^#|\\$SENTINEL)" < .editmsg > .nextmsg
+    if grep "\\$SENTINEL" < .editmsg >/dev/null
+    then
+	:> .editmsg
+	echo "commit aborted - to confirm, delete the sentinel line in the message"
+    fi
+fi
+egrep -v "^#|$SENTINEL" < .editmsg | git-stripspace > .cmitmsg
 [ -s .cmitmsg ] || exit 1
 tree=$(git-write-tree) || exit 1
 commit=$(cat .cmitmsg | git-commit-tree $tree -p $PARENTS) || exit 1
 echo $commit > $GIT_DIR/HEAD
 rm -f -- $GIT_DIR/MERGE_HEAD
+[ -f .nextmsg ] && rm .nextmsg
------------

Re: [PATCH 1/1] Add support for an optional .nextmsg file to git-commit-script

[Junio C Hamano]

>>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> writes:

JS> This change allows a commit message to be prepared prior to git-commit-script being
JS> invoked. During git commit the user is then given an opportunity to edit the
JS> existing message, if any, and must confirm the commit by deleting a sentinel
JS> line from the top of the edit buffer.

JS>  #!/bin/sh
JS> +SENTINEL="*** delete this line to confirm the commit ***"
JS> ..
JS> +egrep -v "^#|$SENTINEL" < .editmsg | git-stripspace > .cmitmsg

A handful comments.

(1) Although it happens to work in this case, I do not like
    scripts that use grep without quoting metacharacters in a
    string.  You have two egreps that phrases the above slightly
    differently.  Make up your mind ;-) and pick one.

(2) What happens if I later want to make a commit with this commit
    log?

    [PATCH] Reword the sentinel line.

    Instead of saying "*** delete this line to confirm the commit ***",
    just say "# If you want to abort the commit, make this file empty.".

(3) The original implementation knows that the commit is to be
    aborted when resulting .cmitmsg is empty.  You may want to
    tell the user in the comment in the commit template about
    it, instead of using the sentinel line.

(4) Instead of teaching git-commit-script about the .nextmsg
    file, it may be cleaner to split it into two parts:

    - one that prepares the .cmitmsg file for editing;

    - the other that invokes the editor on prepared a .cmitmsg
      file, checks if the message file is edited and asks for
      confirmation to abort if the file is unchanged, and does the
      actual commit.

   The new git-commit-script would prepare its .cmitmsg the way it
   does now and only call the latter half.  Your re-commit script
   can do the first half differently from what git-commit-script
   does, and call the same latter half.

P.S. I see you are using "git format-patch"; I'd suggest you
hand edit " 1/1" out of [PATCH 1/1] subject line for a patch
like this that is not part of a series.  I did not special case
1/1 to do it myself because I often have a handful independent
patches and end up removing 1/7 2/7 ... etc. anyway.