Thread (14 messages) flat view 14 messages, 4 authors, 2016-06-15

Re: .gittattributes handling has deficiencies

From: <hidden>
Date: 2016-06-15 22:43:43

On Sun, 21 Oct 2007, Steffen Prohaska wrote:
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.

David Lang
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help