threads / patch / 1351

patchadd "-f" option to git-commit-script to force commit withoutchanges

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

## tl;dr

3 messages between Jul 28, 2005 and Jul 29, 2005. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Johannes Schindelin· Jul 28, 2005, 14:47 UTC · lore

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

Show changes to git-commit-script +6 −2

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

Junio C Hamano· Jul 29, 2005, 02:24 UTC · re: Johannes Schindelin · lore

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

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?

Johannes Schindelin· Jul 29, 2005, 11:06 UTC · re: Junio C Hamano · lore

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

Hi,

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

Show 7 quoted lines

> 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