Re: [PATCH v2 1/2] mingw: introduce the 'core.hideDotFiles' setting

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 9 May 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>> 
>> > +core.hideDotFiles::
>> > +	(Windows-only) If true, mark newly-created directories and files whose
>> > +	name starts with a dot as hidden.  If 'dotGitOnly', only the `.git/`
>> > +	directory is hidden, but no other files starting with a dot.  The
>> > +	default mode is to mark only the `.git/` directory as hidden.
>> 
>> I think "The default mode is 'dotGitOnly'" is sufficient, given that
>> it is described just one sentence before, which is still likely to
>> be in readers' mind.  But I'll let it pass without tweaking.
>
> Yeah, when rewriting this after Ramsay pointed out the erroneous
> documentation, I wanted to fail on the crystal-clear side.

Saying the same thing twice in rapid succession does not make it
any clearer, though.  If you are rerolling anyway, then I think it
would be better to shorten it to clarify.

>> The other is why you do not have to retry creation in a similar way
>> when !needs_hiding(filename).  I didn't see anything in the function
>> before reaching this point that does anything differently based on
>> needs_hiding().  Can't the same 'ERROR_ACCESS_DENIED' error trigger
>> if CREATE_ALWAYS was specified and file attributes of an existing
>> file match, and if it can, don't you want to retry that too, even if
>> you are not going to hide the filename?
>
> The attributes that can trigger the ERROR_ACCESS_DENIED error are the
> hidden flag and the system flag. Since Git *never* marks any file as
> system file, we should be safe.

I was just wondering Git's trying to open it via this codepath
trigger the "if CREATE_ALWAYS was specified and an already existing
file's attributes do not match *exactly*.", if the path is already
hidden.  But again, I am clueless on Windows API, expected use
pattern of Git for Windows, and your future project plans
(e.g. basing future work on Karsten's clean-up patch), so I defer to
your judgment.

> Anyway, the next iteration of this patch is on its way.

OK.  Thanks.