Junio C Hamano wrote: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > >>>> + 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? > > 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 >>>> +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. > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html