[PATCH] add "-f" option to git-commit-script to force commit withoutchanges

[PATCH] add "-f" option to git-commit-script to force commit withoutchanges

[Johannes Schindelin]

Sometimes a failed automatic merge means that we do not want those
changes. In this case, it is desirable to commit the current HEAD (as if
actually something was merged).

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 git-commit-script |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

89e6c9495d7877e9922b22d6c87f51c6902b7056
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -6,12 +6,16 @@
 . git-sh-setup-script || die "Not a git archive"

 usage () {
-	die 'git commit [-m existing-commit] [<path>...]'
+	die 'git commit [-f] [-m existing-commit] [<path>...]'
 }

+force=false
 while case "$#" in 0) break ;; esac
 do
     case "$1" in
+    -f) shift
+        force=true
+        ;;
     -m) shift
         case "$#" in
 	0) usage ;;
@@ -82,7 +86,7 @@ else
 	fi >.editmsg
 	git-status-script >>.editmsg
 fi
-if [ "$?" != "0" ]
+if [ "$?" != "0" -a $force = false ]
 then
 	cat .editmsg
 	rm .editmsg

Re: [PATCH] add "-f" option to git-commit-script to force commit withoutchanges

[Junio C Hamano]

While I agree there should be a graceful way to go back to the
original head from a failed merge situation, I do not think
"committing the current HEAD" is the right model for the end
user to think about it.

Wouldn't using "checkout -f" to revert to the version you would
want to go back work as expected?

Re: [PATCH] add "-f" option to git-commit-script to force commit withoutchanges

[Johannes Schindelin]

Hi,

On Thu, 28 Jul 2005, Junio C Hamano wrote:

> While I agree there should be a graceful way to go back to the
> original head from a failed merge situation, I do not think
> "committing the current HEAD" is the right model for the end
> user to think about it.
>
> Wouldn't using "checkout -f" to revert to the version you would
> want to go back work as expected?

I had the following situation: in a throw away tree I made some changes.
The last conflicted with a change I pulled from somewhere else into the
master, and the best solution was to revert that last change from the
throw away tree. Basically, the result of the merge was identical to
master, i.e. git-status says "nothing to commit". I wanted to document,
however, that I do not want that change from the throw away tree in my
master, even if I keep it in the throw away tree.

I am no longer sure if that was a good thing to do, maybe I should have
fixed it in the throw away tree by merging master there. Or, alternatively
git-commit could check for "nothing to commit" OR "MERGE_HEAD exists".
Dunno.

Ciao,
Dscho