Re: [PATCH 3/3] git-pull.sh: introduce --[no-]autostash and pull.autostash

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

 



Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:

> @@ -1786,6 +1786,11 @@ pull.rebase::
>  	of merging the default branch from the default remote when "git
>  	pull" is run. See "branch.<name>.rebase" for setting this on a
>  	per-branch basis.
> +
> +pull.autostash::
> +	When true, automatically stash all changes before attempting to
> +	merge/rebase, and pop the stash after a successful
> +	merge/rebase.
>  +
>  *NOTE*: this is a possibly dangerous operation; do *not* use
>  it unless you understand the implications (see linkgit:git-rebase[1]

Is autosquash a possibly dangerous operation?

> @@ -196,7 +203,8 @@ test true = "$rebase" && {
>  		then
>  			die "$(gettext "updating an unborn branch with changes added to the index")"
>  		fi
> -	else
> +	elif test "$autostash" = false
> +	then
>  		require_clean_work_tree "pull with rebase" "Please commit or stash them."
>  	fi

A safety net, after you run "git stash", to validate that the
added "git stash" indeed made the working tree clean, is necessary
below, but there does not seem to be any.

>  	oldremoteref= &&
> @@ -213,6 +221,12 @@ test true = "$rebase" && {
>  		fi
>  	done
>  }
> +
> +stash_required () {
> +	! (git diff-files --quiet --ignore-submodules &&
> +	git diff-index --quiet --cached HEAD --ignore-submodules)
> +}
> +
>  orig_head=$(git rev-parse -q --verify HEAD)
>  git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
>  test -z "$dry_run" || exit 0
> @@ -288,4 +302,12 @@ true)
>  	eval="$eval \"\$merge_name\" HEAD $merge_head"
>  	;;
>  esac
> -eval "exec $eval"
> +
> +if test "$autostash" = true && stash_required
> +then
> +	git stash
> +	eval "$eval"
> +	test $? = 0 && git stash pop
> +else
> +	eval "exec $eval"
> +fi

Delaying to run "git stash" as much as possible is fine, but with
the above, can the user tell if something was stashed and she has
to "stash pop" once she is done helping the command to resolve the
conflicts, or she shouldn't run "stash pop" after she is done
(because if nothing is stashed at this point, that "pop" will pop an
unrelated stash)?

What protects the "git stash" from failing and how is its error
handled?
--
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]