Am 5/13/2014 11:09, schrieb Erik Faye-Lund:
> On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest
> <> 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
More majordomo info at

Reply via email to