Junio C Hamano wrote:
> 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?
Oops. I must admit I was in a bit of a hurry with the documentation.
I was eager to send out the series seeing that the tests were passing.
>> @@ -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.
Um, isn't that part of the "git stash" testsuite?
>> 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)?
I could easily tell, from the "git pull" output: if conflict, then
stash hasn't been applied. Otherwise, yes. Should we print a message
guarded by an advice variable?
> What protects the "git stash" from failing and how is its error
> handled?
Oh, this is my stupidity. I should've just &&-chained the git stash,
eval $eval, and git stash pop.
--
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