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 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". -- 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