[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Bug - Git reset --quiet not quiet
From:       Johannes Sixt <j.sixt () viscovery ! net>
Date:       2014-05-13 9:38:32
Message-ID: 5371E818.1090001 () viscovery ! net
[Download RAW message or body]

Am 5/13/2014 11:09, schrieb Erik Faye-Lund:
> On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest
> <tllaforest@arbault.ca> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]