Bug - Git reset --quiet not quiet

Bug - Git reset --quiet not quiet

[Thomas-Louis Laforest]

Good afternoon,

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.

Good day

Thomas-Louis Laforest, ing. jr, Jr. Eng.
Chargé de projet, Project Leader
solutions intégrées  |  integrated solutions
T 819 542-5600  x3106
F 819 845-5600
tllaforest@arbault.ca
The information contained herein is of private and confidential nature. It can be used only by the above-mentioned recipients. Any other person who would take note of it is advised that it is strictly forbidden for him to reveal the information, to distribute it or to copy it. If this communication were transmitted to you by mistake, warn us immediately by telephone or email, and erase the original, without taking a copy, revealing the content nor taking some measures based on it.
Les renseignements contenus dans les présentes sont de nature privée et confidentielle. Ils ne peuvent être utilisés que par le ou les destinataires susmentionnés. Toute autre personne qui en prendrait connaissance est priée de noter qu'il lui est strictement interdit de les divulguer, de les distribuer ou de les copier. Si cette communication vous a été transmise par mégarde, veuillez nous en aviser immédiatement par téléphone ou par courriel, et effacer l'original, sans en tirer de copie, en dévoiler le contenu ni prendre quelque mesure fondée sur celui-ci.

Re: Bug - Git reset --quiet not quiet

[Erik Faye-Lund]

On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest
<tllaforest@arbault.ca> wrote:
> Good afternoon,
>
> 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.

Thanks for reporting this.

The problem here is really a nasty case of layering: the question
comes from a place deep inside the OS compatibility layer, which
doesn't know about the --quiet flag.

However, do note that if fixed, the command would still fail under
these conditions. But it won't hang forever, as it does now.

Mainline Git-folks: The problem here is essentially unlink returning
EBUSY (although that's not *exactly* what happes - but it's close
enough, implementation details in mingw_unlink), which most of the git
codebase assume won't happen. On Windows, this happens *all* the time,
usually due to antivirus-software scanning a newly written file. We
currently retry a few times with some waiting in mingw_unlink, and
then finally prompts the user. But this gives the problem described
above, as mingw_unlink has no clue about --quiet.

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.

Option 1) seems quite error-prone to me - it's difficult to make sure
all code-paths actually set this flag, so there's a good chance of
regressions. Option 2) also sounds a bit risky, as we lose stdout
forever, with no escape-hatch. So to me option 3) seems preferable
although it might translate into a bit of churn. Thoughts?

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug - Git reset --quiet not quiet

[Johannes Sixt]

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

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug - Git reset --quiet not quiet

[Erik Faye-Lund]

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

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.