[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:09:43
Message-ID: CABPQNSaj3xwknXsrYnF35tcDAmTwK5KALOsUOgHF_hrEf2H_+g () mail ! gmail ! com
[Download RAW message or body]

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?
--
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]