Re: Line ending normalization doesn't work as expected

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2018, 19:16 UTC
Message-ID: <xmqqvaey83my.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAHd499CSe6d1SBaDYNRD9HXaWRJ9QYzmOCaBWFrV52UNRMVqhA@mail.gmail.com>

Robert Dailey <rcdailey.lists@gmail.com> writes:

Show 19 quoted lines

> On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Torsten Bögershausen <tboegi@web.de> writes:
>>
>>>> $ git rm -r --cached . && git add .
>>>
>>> (Both should work)
>>>
>>> To be honest, from the documentation, I can't figure out the difference between
>>> $ git read-tree --empty
>>> and
>>> $ git rm -r --cached .
>>>
>>> Does anybody remember the discussion, why we ended up with read-tree ?
>> ...
>
> Sorry to bring this old thread back to life, but I did notice that
> this causes file modes to reset back to 644 (from 755) on Windows
> version of Git. Is there a way to `$ git read-tree --empty && git add
> .` without mucking with file permissions?

I think the message you are referring to is a tangent that discusses how it was done in the old world, with issues that come from the fact that with such an approach the paths are first removed from the index and then added afresh to the index, which can lose cases and executable bits when working on a filesystem that does not retain enough information.

The way in the new world is to use "add --renormalize" which was added at 9472935d ("add: introduce "--renormalize"", 2017-11-16), I think.