Re: [PATCH] mingw: fix regression in t1308-config-set

[Jeff King <peff@peff.net>]

On Thu, Jul 14, 2016 at 09:18:18AM -0700, Junio C Hamano wrote:

> I added a few missing Cc: and quoted the whole patch here to those
> who were involved; I think this update is correct, but just trying
> to make sure people know.
> 
> Not limited to this particular topic, there probably are some things
> we can and should add to the procedure to prevent further episodes
> like this, but I am not seeing anything immediately obvious offhand.
> There already is a way to prominently mark a topic to be not-ready
> with an outstanding issue called "What's cooking" report, but it is
> maintained manually and it can be leaky without extra set of eyes
> constantly monitoring.

Thanks, this fix looks good.

I'm open to to suggestions to make life easier for Windows folks.
Usually when dealing with paths, the suggestion is to use $(pwd), which
I did in the original, but as 58461bd noted, that broke other cases.

So code-wise, maybe this technique could be more general. I.e., could
$TRASH_DIRECTORY or $HOME already be in whatever format is likely to be
produced by git on the platform? Or does that just screw things up more
because Windows sometimes needs one form and sometimes the other?

Process-wise, I'm not sure. I seem to recall a few times when Windows
issues have come up in the past that somebody (JSixt?) seemed content to
let topics graduate with potential portability problems, and then have
the Git for Windows project fix them up separately. These days GfW seems
to track upstream more closely (which is wonderful!), but it means
portability problems cause a more immediate headache and slow down that
process.

> > 	Side note: it was not at all clear to me how 58461bd fixed the
> > 	problem by replacing $(pwd) with $HOME, given that HOME is set to
> > 	$TRASH_DIRECTORY which is set to $TEST_OUTPUT_DIRECTORY/... after
> > 	TEST_OUTPUT_DIRECTORY was set to TEST_DIRECTORY which in turn was
> > 	set to $(pwd).
> >
> > 	I guess the reason is that -P in `cd -P "$TRASH DIRECTORY"`, but
> > 	then I *really* do not understand how $(pwd) and $PWD could
> > 	disagree.

I don't think they did disagree. The issue is that "cd -P" caused _both_
of them to print the physical directory. But git is not using either of
them. It is blindly using "$HOME". So basically:

  HOME=/path/with/symlinks
  cd -P "$HOME"

will cause "$PWD" and "$HOME" to disagree. Likewise with "$(pwd)" and
"$HOME".

-Peff