Re: [RFC PATCH] am: do not do any reset on --abort

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> We really have no idea what state the tree is in at this
> point, and whether the user might have done useful work on
> top of it. So let's err on the side of keeping the user's
> data intact.
>
> The downside is that if they do have cruft to get rid of, or
> want to pretend as if earlier parts of the series that were
> applied did not exist, they must manually "git reset --hard"
> now.

I do not see it as a major downside, but not telling them that they may
want to when we avoid doing it ourselves might be.

> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> This is a followup to:
>
>   http://thread.gmane.org/gmane.comp.version-control.git/118373
>
>  git-am.sh |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/git-am.sh b/git-am.sh
> index 578780b..a7e24cf 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -240,10 +240,6 @@ then
>  			exec git rebase --abort
>  		fi
>  		git rerere clear
> -		test -f "$dotest/dirtyindex" || {
> -			git read-tree --reset -u HEAD ORIG_HEAD
> -			git reset ORIG_HEAD
> -		}
>  		rm -fr "$dotest"
>  		exit ;;
>  	esac
> -- 
> 1.6.3.1.250.g01b8b.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]