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

List:       git
Subject:    Re: Bug - Git reset --quiet not quiet
From:       Erik Faye-Lund <kusmabite () gmail ! com>
Date:       2014-05-13 9:42:08
Message-ID: CABPQNSbw335wEeDfc+3Jg2X+Zv2422vPf5P5Wwm8NWbuYPMVQA () mail ! gmail ! com
[Download RAW message or body]

On Tue, May 13, 2014 at 11:38 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> 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).

Well, sure. But if sounds like surprising behavior to me. And I also
suspect doing this unconditionally on all platforms will fix strange
corner-cases on other systems, when using Windows file-systems. AFAIK,
the whole "cannot delete an open file"-thing is an NTFS-detail (and
possibly also FAT, which is quite commonly used on non-Windows).
--
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]