Re: end-of-line diff checkout direction dependence problem

From: Torsten Bögershausen <tboegi@web.de>
Date: Jul 6, 2015, 06:53 UTC
Message-ID: <559A25E0.1090908@web.de>
In-Reply-To: <559543E9.5040706@ivision.de>

On 2015-07-02 16.00, Thomas Vieten wrote: []

> see the file attachend to the end of this message

Thanks for the info

Show 15 quoted lines

>
>> It may be, that you need to "nornalize" your repo:
>>
> in principle we know all this.
> What is remarkable that we are able to checkout a version of master which is
> not consistent with the repo, and more, dependent from the checkout direction
> (if the direction is the positive or negative history in time). And on the
> other hand we can checkout a version of master which is in sync with the master.
>
> Normally such conflicts with not normalised repos appear immediately also in
> positive history direction. And then it is possible to detect them.
> The other way around - negative history and diffs - it causes a big questionmark.
>
> On the other hand this would lead to the mandatory work flow advice: "Always
> normalize the repository after changes within the gitattributes file"

Yes, I think this sounds reasonable, and I think the documentations says this. But it is a manual step, which is typically done only once. It there anything which can be improved here ?

> And then: Should this then not be automatically be done somehow in the
> background by git ?

This could make sense, but the word "background" should mean visible to the user ? Recently we got the "untracked cache" into Git, which keeps track about the .gitignore files A similar logic can be used to keep track of the .gitattributes file(s) (There can be more than one) Patches are welcome.

>
> Reasoning: if the "git machine" is causing this behaviour systematically,
> shouldn't the machine itself have compensation, correction?
>

Question 1: The documentation should be clear enough:
 Whenever someone "introduces .gitattributes," the repo should be normalized.

> Depending on your point of view this could be seen as a bug.

I have run into this myself, but never in a reproducable way. The day I can reproduce it, I may send a patch. Or, somebody else sends a patch before that day.

>
> There is also a big question open: will normalisation really help ? Because
> there must be one commit with the new gitattributes and then you normalize.

To my experience it does.
 Normalizing means one single commit (not 2), including the .gitattributes and
the normalized files.
Question 2:
Is there something in the documentation that could be improved.

Show 10 quoted lines

> But the "wrong diff" is in the repo and will cause the problem when going back
> to master in the negative direction.
> This is how understand it up to now.
>
> But at this point git is complex and we are not really the experts.
>
> best regards
>
> Thomas V.
>

Thanks for the report(s)