Re: Bug Report

From: Torsten Bögershausen <tboegi@web.de>
Date: Apr 21, 2022, 17:52 UTC
Message-ID: <20220421175254.54y7dzxhtu33wu6w@tb-raspi4>
In-Reply-To: <AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM>

On Thu, Apr 21, 2022 at 03:29:20PM +0000, Daniel Habenicht wrote:

Show 18 quoted lines

> Hi Torsten,
>
> thanks for your answer.
> As I explained in the reproduction, I now know why this is happening and I successfully resolved it for my repository.
> I just wanted raise awareness that it is not self-explanatory to non-professional users.
>
> I would suggest two changes:
>
>   1.  Warn the user on commit of the .gitattributes that he also needs to renormalize the repository (or even better, do that by default).
>   2.  Include the information about the need for a renormalization commit on checkouts/restores/reset if there are still files not updated (shown as modified).
>
> Regarding the "Users which are confused may put their frustration aside and read the documentation".
> I think most users won't make the connection for the first 3 google searches, if the problem arises only several commits after the gitattributes change, or if the repository gets cloned by a new user.
>
>
> Cheers,
> Daniel
>

(Sorry for the top-posting before, this list uses bottom-posting)

I still hope that users who are able to find the feature of the .gitattributes file(s) are able to find out about the renormalaztion as well. And you are not the first one who runs into this problem, if that is of any comfort.

Now, back to your suggestions: The way Git works does not seam to allow a reliable detection of files that are "modified" after a checkout/restore/reset when .gitattributes change. (Someone may correct me if this is wrong. It is related/connected to the timestamps of "the index" and the files in the working tree and the fact that "git add" will need to store a new version of the file in the repo e.g CRLF -> LF)

Automatically doing a renormalization seems to be an impossible thing: The commit as such is atomic, including all files in the working tree with their line endings and the .gitattributes file itself. Changing things here seems the wrong way to go, at least for me.

Showing a hint when a .gitattributes file is commited may be more feasable. I haven't digged which part of the code would be the best place.

Patches and ideas are welcome