Junio C Hamano wrote:
> Ramkumar Ramachandra <artag...@gmail.com> writes:
>>>> + elif test "$autostash" = false
>>>> + then
>>>> require_clean_work_tree "pull with rebase" "Please commit or
>>>> stash them."
>>> 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?
> You should always "trust but verify" what other commands do at key
> points of the operation; and I think this "require-clean-work-tree"
> is a key precondition for this mode of operation to work correctly.
> Especially because you do not even bother to check the result of
> "git stash" before continuing ;-).
If you think it's enough to replicate the codepath that precedes the
actual saving in 'git stash' (which is essentially
require-clean-work-tree), I'm in agreement with you. I thought you
were implying a wider safety net, that wouldn't even assume the basic
sanity of stash.
>>>> +if test "$autostash" = true && stash_required
>>>> + git stash
>>>> + eval "$eval"
>>>> + test $? = 0 && git stash pop
>>>> + eval "exec $eval"
>>> 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.
> The question was about "git stash save". Depending on the cleanness
> of the tree when "git pull" was started, "save" may or may not have
> been done. After resolving a conflicted "git pull" and committing
> the result, the user does not have much clue if she needs to pop
> anything, does she? Instead of the usual "resolve the conflicts and
> commit the result", she may need to see "resolve the conflicts,
> commit the result, *AND* UNSTASH".
Yes, good point. Will it suffice to print a message?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html