Re: Bug - Git reset --quiet not quiet

On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest <tllaforest@arbault.ca> wrote:

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?