On Thu, Apr 27, 2017 at 12:07 PM, Johannes Sixt <j...@kdbg.org> wrote: > Am 27.04.2017 um 02:57 schrieb Junio C Hamano: >> >> Johannes Sixt <j...@kdbg.org> writes: >> >>> +++ git ls-remote 'refs*master' >>> +warning: unable to access '.git/branches/refs*master': Invalid argument >>> fatal: 'refs*master' does not appear to be a git repository >>> fatal: Could not read from remote repository. >>> >>> Please make sure you have the correct access rights >>> and the repository exists. >>> +++ exit_code=128 >>> >>> On Windows, it is not allowed to pass a file name with an asterisk to >>> the OS. The test case contains this comment: >>> >>> # We could just as easily have used "master"; the "*" emphasizes its >>> # role as a pattern. >>> >>> So, can we replace the name with a simple "master", our would this >>> miss the goal of the test case? Should we make it conditional on the >>> MINGW prerequisite? >> >> >> I would actually be more worried about the real-life impact of this >> change. Those who did "git ls-remote 'refs*master'" merely got "it >> does not appear to be a git repository" and that was entirely sensible >> response from the command. Can Windows folks live with an extra >> warning before it, or do they object to see that new warning? > > > I was also worried that the new warning may be irritating. However, I expect > that it is seen in practice only after a typo. My gut feeling is that this > is bearable, because the reason for the warning should be obvious. > > Unless a use-case turns up where the pattern occurs routinely. We'll have to > keep the eyes open. Until then it is better to keep the change, IMO.
OK I'll just add MINGW to the test then. Windows folks can improve warn_on_inaccessible() to suppress certain class of error messages if needed. -- Duy
