Skip to contentSkip to conversation

Teach git-reset to let others override its reflog entry.

PATCH In review Shawn O. Pearce 3 participants 4 messages Jun 15, 2016 Documentation

lore
Share & tools
lore
#0 lore raw

PATCH 1/2 Teach git-reset to let others override its reflog entry.

When git-rebase invokes git reset --hard to rewind the user's branch prior to starting to reapply each commit this is showing up in the reflog as a simple git reset --hard <cmt> but its not clear to the end-user inspecting the log why there is a reset.

The new --reflog-action for git-reset behaves like the same option to git-merge; it can be used by the caller to override the message entry in the reflog and is intended to be used only when git-reset is acting as plumbing, not porcelain.

---
 Documentation/git-reset.txt |    5 +++++
 git-rebase.sh               |    4 ++--
 git-reset.sh                |    8 ++++++--
 3 files changed, 13 insertions(+), 4 deletions(-)
Documentation/git-reset.txt +5 -0
index 4f42478..7eaa186 100644
@@ -45,6 +45,11 @@ OPTIONS
 	switched to. Any changes to tracked files in the working tree
 	since <commit> are lost.
 
+--reflog-action=<action>::
+	This is used internally when `git-rebase` calls this command
+	to reset the current branch prior to merging the rebased
+	commits onto it.
+
 <commit>::
 	Commit to make the current HEAD.
 
git-rebase.sh +2 -2
index ece3142..b99f1e3 100755
@@ -174,7 +174,7 @@ do
 		else
 			die "No rebase in progress?"
 		fi
-		git reset --hard ORIG_HEAD
+		git reset --reflog-action="rebase: abort" --hard ORIG_HEAD
 		exit
 		;;
 	--onto)
@@ -293,7 +293,7 @@ fi
 
 # Rewind the head to "$onto"; this saves our current head in ORIG_HEAD.
 echo "First, rewinding head to replay your work on top of it..."
-git-reset --hard "$onto"
+git-reset --hard --reflog-action="rebase: rewind to $onto_name" "$onto"
 
 # If the $onto is a proper descendant of the tip of the branch, then
 # we just fast forwarded.
git-reset.sh +6 -2
index 2379db0..7ef6789 100755
@@ -6,7 +6,7 @@ USAGE='[--mixed | --soft | --hard]  [<commit-ish>] [ [--] <paths>...]'
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
 
-update= reset_type=--mixed
+rloga= update= reset_type=--mixed
 unset rev
 
 while case $# in 0) break ;; esac
@@ -15,6 +15,9 @@ do
 	--mixed | --soft | --hard)
 		reset_type="$1"
 		;;
+	--reflog-action=*)
+		rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+		;;
 	--)
 		break
 		;;
@@ -81,7 +84,8 @@ then
 else
 	rm -f "$GIT_DIR/ORIG_HEAD"
 fi
-git-update-ref -m "reset $reset_type $*" HEAD "$rev"
+test "$rloga" = '' && rloga="reset $reset_type $*"
+git-update-ref -m "$rloga" HEAD "$rev"
 update_ref_status=$?
 
 case "$reset_type" in
Signature · 1 line
1.4.4.3.gd2e4
#1 lore raw
Quoted 4 lines · Shawn O. Pearce

The new --reflog-action for git-reset behaves like the same option to git-merge; it can be used by the caller to override the message entry in the reflog and is intended to be used only when git-reset is acting as plumbing, not porcelain.

Honestly, I hate these --reflog-action options everywhere.

I wonder if something like this would be easier to manage in the longer run:

* In git-sh-setup.sh, have this shell function.

	set_reflog_action () {
		if test -z "${GIT_REFLOG_ACTION+set}"
                then
                	GIT_REFLOG_ACTION="$*"
                        export GIT_REFLOG_ACTION
		fi
	}

* Begin git-reset.sh with something like this:

	#!/bin/sh

	. git-sh-setup
	set_reflog_action "reset $*"

* Update Porcelain-ish commands that use git-reset in the same way. For example, git-rebase could say:

	#!/bin/sh

	. git-sh-setup
	set_reflog_action "rebase $*"

Then calls to "git-update-ref -m" could use the value of "$GIT_REFLOG_ACTION", without explicit --reflog-action= parameters and $rloga variables.

Hmm?

#2 lore raw
Quoted 8 lines · Junio C Hamano
Quoted 4 lines · Shawn O. Pearce

The new --reflog-action for git-reset behaves like the same option to git-merge; it can be used by the caller to override the message entry in the reflog and is intended to be used only when git-reset is acting as plumbing, not porcelain.

Honestly, I hate these --reflog-action options everywhere.

Me too. Yet I submit patches to add them. ;-)

Quoted 3 lines

Then calls to "git-update-ref -m" could use the value of "$GIT_REFLOG_ACTION", without explicit --reflog-action= parameters and $rloga variables.

I agree. Your suggestion is way more elegant.

I have some more git-am/git-merge/git-pull/git-rebase patches brewing; I'm finishing the commit message for the last in the sequence. I'll update it to include your suggestion and try to start cleaning up this --reflog-action mess, then ship the series out to the list, including this mini 2 patch series you are rejecting for good reason.

Signature · 1 line
Shawn.
#3 lore raw
In reply to Junio C Hamano
Quoted 3 lines · Junio C Hamano

Then calls to "git-update-ref -m" could use the value of "$GIT_REFLOG_ACTION", without explicit --reflog-action= parameters and $rloga variables.

I think that --reflog-action should then be used to set GIT_REFLOG_ACTION, slightly similarly to how --git-dir sets GIT_DIR variable.

Signature · 3 lines
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git