Re: .gittattributes handling has deficiencies

On Oct 21, 2007, at 7:57 PM, david@lang.hm wrote:

On Sun, 21 Oct 2007, Steffen Prohaska wrote:

quoted

On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:

quoted

On Sun, 21 Oct 2007, Steffen Prohaska wrote:

quoted

On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:

quoted

quoted

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.

What do you mean by "checking out everything"?
Which command do you propose?

something like git checkout -f

I suspected this. I see two problems:

1) it's too dangerous: I throws away _all_ changes, not only
changes that are related to gitattributes.

2) it doesn't work reliably. git checkout -f will only update
files that git detects as changed. But you could have files that
should have crlf in the working copy but actually have only lf.
Those would not be updated.

I'll not recommend this. Not using .gitattributes is the only
sane solution.

	Steffen