Hi Junio, On Mon, 17 Oct 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> I'll mark it as "wait for follow-up fix" in whats-cooking.txt (on > >> 'todo' branch) to remind myself not to merge it yet. > > > > May I request your guidance as to your preference how to proceed? ... > > I guess I didn't see this before I sent my response to the review > thread, which was in my pile of "these need more thought than others > before responding" topics. > > > Here are the options I see: > > > > A) remove the tests in question > > > > B) mark them as !MINGW instead > > > > C) change just those two tests from using `$PWD` (pseudo-Unix path) to > > `$(pwd)` (native path) > > > > I would like to hear your feedback about your preference, but not without > > priming you a little bit by detailing my current opinion on the matter: > > > > While I think B) would be the easiest to read, C) would document the > > expected behavior better. A) would feel to me like shrugging, i.e. the > > lazy, wrong thing to do. > > > > What do you think? > > As to my preference on tests, I guess what I suggested was a cross > between your B and C below, and I can go with either one as an > abbreviated version of my preference ;-) > > I am still wondering if the test is expecting the right behaviour, > though. If some codepaths rely on a question "please resolve '../.' > relative to 'path/to/dir/.'" being answered as "that's path/to/dir > itself", it smells to me that the downstream of the dataflow that > expects such an answer, as well as the machinery that produces such > an answer, are acting as two wrongs that happen to cancel each > other. Am I grossly misunderstanding what that test is doing? I think your "let's take a step back" was spot on: when being passed a path ending in "/." and being told to normalize the relative path "../." on top, the very special meaning of "." should be taken into consideration. Thanks, Dscho