How to make change to .gitattributes take effect

Question

I\'m working on a project where we have recently started using git. The setup was not perfect from start, so I\'ve set up .gitattributes after people started cloning/working

Answer 1

By "would like this change to take effect", do you mean that Alice wants the working copies to switch to Windows-style line endings for both her and Bob? Then the first problem is, why is Alice taking responsibility for what's in Bob's working tree?

If the file is better described by the new attributes, so be it; the .gitattributes file can be edited, tested, and committed just like any other.

The procedure you suggest for getting the new attributes to take effect doesn't make a lot of sense, for two reasons:

First, why are you wiping the index? The text attribute affects the relationship between the index and the working copy. In your example it seems it's the working copy you need to change, not the index.

Second, why are you wiping everything from the index? Only the paths whose attributes have changed need to be addressed.

So in your example, if Alice wants to locally reflect the new attributes, the most that should be necessary is

rm myproj/src/file.ending
git checkout -- myproj/src/file.ending

Since this procedure doesn't overwrite the .gitattributes file, there's no need to prematurely commit it.

It's not clear to me what exactly makes Bob unhappy about your original procedure, so I don't know if this one makes him any happier. Perhaps he just wants the update to be automatic when he pulls; while it's not unreasonable to expect that, I'm not sure it's in the cards as git works.

The problem is how changes are detected. In almost every situation, if git's updating the working tree at the end of a merge or fast-forward (e.g. completing a pull), it need only compare the hashes of the indexed objects for the old commit and the new commit to tell if there's a change to apply.

The exception is if attributes (or filter definitions) change - as noted above, that doesn't change the index. But those conditions are relatively rare, and the checks for them are much more expensive than hash check that's right almost every time, so rather than burden every comparison with mostly-pointless costs git allows that when you know you've done certain things, you have to take an extra step.

So if this is going to happen once, just let the team communicate. "The attributes for this path are changing; you may want to refresh your working copies of the affected files."

If it's going to happen repeatedly, my best advice is to figure out why this keeps happening and fix it. You could try to set up some kind of scripted automation, maybe even with hooks, to detect and address attribute changes; but it's a lot of complication and will likely cause more trouble than it fixes.