Re: .gittattributes handling has deficiencies

From: david@lang.hm <david@lang.hm>
Date: Oct 21, 2007, 17:09 UTC
Message-ID: <Pine.LNX.4.64.0710211007430.4818@asgard>
In-Reply-To: <B61AE1A9-E983-4ACE-BF71-8FDC113A4F34@zib.de>

On Sun, 21 Oct 2007, Steffen Prohaska wrote:

Show 16 quoted lines

> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>
>>> But this is really hard to solve. We would need to compare
>>> attributes before and after for _all_ files that have attributes
>>> in one of the two commits and check if they changed. If so, we
>>> need to do a fresh checkout according to the new attributes.
>> 
>> if you know that you will get the new .gitattributes if it changes, setup a 
>> post-checkout hook to checkout everything if it has changed. it's far from 
>> ideal, but it should be a good, safe, first approximation.
>
>
> That's not good enough. I'll stop using .gitattributes. I
> need to teach >40 devs how to use git on Windows. I only use
> features that work flawlessly. .gitattributes doesn't. It bit
> me twice now.

why would checking everything out if .gitattributes has changed not work? I can see why _not_ doing so would cause problems, and I freely acknowledge that this approach imposes a performance hit by checking everything out twice, but I don't see how it would not be reliable.

David Lang

Show 5 quoted lines

> Luckily, core.autocrlf works if you set it before the first
> checkout and never change it. This seems sufficient for me if
> all files that have mixed line endings are fixed right away.
>
> 	Steffen