Re: Bug Report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 21, 2022 at 03:29:20PM +0000, Daniel Habenicht wrote:
> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux