Re: Bug - Git reset --quiet not quiet
On Tue, May 13, 2014 at 11:38 AM, Johannes Sixt wrote: > Am 5/13/2014 11:09, schrieb Erik Faye-Lund: >> On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest >> 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 '' 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug - Git reset --quiet not quiet
Am 5/13/2014 11:09, schrieb Erik Faye-Lund: > On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest > 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 '' 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug - Git reset --quiet not quiet
On Mon, May 12, 2014 at 9:16 PM, Thomas-Louis Laforest 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 '' 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
