[PATCH 3/3] rebase -i: use "git sequencer--helper --reset-hard"

[PATCH 3/3] rebase -i: use "git sequencer--helper --reset-hard"

[Christian Couder]

instead of "git reset --hard"

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 git-rebase--interactive.sh |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c9c75c0..0041994 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -154,7 +154,8 @@ pick_one () {
 		die "Could not get the parent of $sha1"
 	current_sha1=$(git rev-parse --verify HEAD)
 	if test "$no_ff$current_sha1" = "$parent_sha1"; then
-		output git reset --hard $sha1
+		git sequencer--helper --reset-hard $sha1 \
+			"$GIT_REFLOG_ACTION" "$VERBOSE"
 		test "a$1" = a-n && output git reset --soft $current_sha1
 		sha1=$(git rev-parse --short $sha1)
 		output warn Fast forward to $sha1
@@ -238,7 +239,8 @@ pick_one_preserving_merges () {
 	case $fast_forward in
 	t)
 		output warn "Fast forward to $sha1"
-		output git reset --hard $sha1 ||
+		git sequencer--helper --reset-hard $sha1 \
+			"$GIT_REFLOG_ACTION" "$VERBOSE" ||
 			die "Cannot fast forward to $sha1"
 		;;
 	f)
@@ -536,7 +538,8 @@ first and then run 'git rebase --continue' again."
 			git symbolic-ref HEAD $HEADNAME
 			;;
 		esac &&
-		output git reset --hard $HEAD &&
+		git sequencer--helper --reset-hard $HEAD \
+			"$GIT_REFLOG_ACTION" "$VERBOSE" &&
 		rm -rf "$DOTEST"
 		exit
 		;;
@@ -548,7 +551,9 @@ first and then run 'git rebase --continue' again."
 		git rerere clear
 		test -d "$DOTEST" || die "No interactive rebase running"
 
-		output git reset --hard && do_rest
+		git sequencer--helper --reset-hard HEAD \
+			"$GIT_REFLOG_ACTION" "$VERBOSE" &&
+		do_rest
 		;;
 	-s)
 		case "$#,$1" in
-- 
1.6.4.133.g8a5c8

Re: [PATCH 3/3] rebase -i: use "git sequencer--helper --reset-hard"

[Sverre Rabbelier]

Heya,

On Sun, Aug 2, 2009 at 19:40, Christian Couder<chriscool@tuxfamily.org> wrote:
> instead of "git reset --hard"

Hmmm, why though? The commit message (either this one or those earlier
in the series) don't really explain. What are the advantages of using
this new 'git reset --hard' alternative?

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH 3/3] rebase -i: use "git sequencer--helper --reset-hard"

[Christian Couder]

Hi,

On Monday 03 August 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Aug 2, 2009 at 19:40, Christian Couder<chriscool@tuxfamily.org> 
wrote:
> > instead of "git reset --hard"
>
> Hmmm, why though? The commit message (either this one or those earlier
> in the series) don't really explain. What are the advantages of using
> this new 'git reset --hard' alternative?

This is part of my work to port git-rebase--interactive.sh to C using code 
from the sequencer project. So the advantage is that it introduces and uses 
the reset_almost_hard() function that will be used in the end when 
everything is done by C code.

Regards,
Christian.

Re: [PATCH 3/3] rebase -i: use "git sequencer--helper --reset-hard"

[Sverre Rabbelier]

Heya,

On Sun, Aug 2, 2009 at 23:29, Christian Couder<chriscool@tuxfamily.org> wrote:
> This is part of my work to port git-rebase--interactive.sh to C using code
> from the sequencer project. So the advantage is that it introduces and uses
> the reset_almost_hard() function that will be used in the end when
> everything is done by C code.

Hmmm, that almost makes sense, but I don't see the new C code
replacing any existing shell code, so what am I missing here?

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH 3/3] rebase -i: use "git sequencer--helper --reset-hard"

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> Heya,
>
> On Sun, Aug 2, 2009 at 23:29, Christian Couder<chriscool@tuxfamily.org> wrote:
>> This is part of my work to port git-rebase--interactive.sh to C using code
>> from the sequencer project. So the advantage is that it introduces and uses
>> the reset_almost_hard() function that will be used in the end when
>> everything is done by C code.
>
> Hmmm, that almost makes sense, but I don't see the new C code
> replacing any existing shell code, so what am I missing here?

More importantly, I found the "almost_hard()" function way underexplained.
What it does (e.g. does --hard when able but otherwise gives up and falls
back to something else?), why it is necessary (e.g. when should callers
use it, instead of calling unconditional "reset --hard"?), what kind of
preparation is necessary by the caller (e.g. should it read the index
before calling the function?  should it discard the index before?), and
what kind of result should it expect (e.g. is it safe to write a tree out
of the resulting index, or does it screw up the cache-tree and the caller
should discard it before writing a tree?), etc. etc....