Am 5/13/2014 11:09, schrieb Erik Faye-Lund: > On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest > <tllaforest@xxxxxxxxxx> wrote: >> When running this command on Git for Windows (version 1.9.2-preview20140411) >> git reset --quiet --hard with one file having read/write lock git ask this question : >> Unlink of file 'XXXX' failed. Should I try again? (y/n) >> >> I will have expected the command --quiet to remove the question and auto-answer no. >> This broke an automated script we use. ... > I guess this could be solved in a few ways. > 1) Let mingw_unlink() know about the quiet-flag. This probably > involves moving the quiet-flag from each tool into libgit.a. > 2) Make the quiet-flags close stdout instead of suppressing every output. > 3) Make the higher level call-sites of Git EBUSY-aware. This probably > involves making an interactive convenience-wrapper of unlink, that > accepts a quiet flag - similar to what mingw_unlink does. Is any of this really needed? We have this in ask_yes_no_if_possible(): if (!isatty(_fileno(stdin)) || !isatty(_fileno(stderr))) return 0; i.e., we answer "no" automatically without asking if at least one of stdin and stderr are not a terminal. Perhaps the OP's problem is that they do not redirect these channels to files or something in their automated scripts? In particular, it should be sufficient to redirect stdin from /dev/null (a.k.a. "nul" on Windows). -- Hannes -- 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