Investigate precidence order in `.gitattributes` and what happens when multiple filters are used.

[blester125]

Currently when adding the checkpoint to .gitattributes file, we will add the filter=theta to any line that matches our model checkpoint. This might be over eager.

In the case where they have a rule like *.pt that they are tracking with some overfilter, like git lfs, does adding our filter to this attribute (instead of adding an exact match rule at the end) cause issues? Either with other files that match this pattern or our model getting these filters run on it?

Part of this hinges on how git handles multiple filters and multiple matches.

[blester125]

I did some exploration of what happens when there are multiple filters/multiple lines that match.

When multiple lines in .gitattributes match a file, the last line is the one that is used.
When a line has multiple filter keys (i.e. filter=lfs filter=theta) the last filter is the one used.
Extra key=value pairs not used by git are ignored.

[craffel]

Should we warn the user when they are trying to track a file that already has a filter key defined? Since they might not expect past filters to stop working?

[blester125]

#227 copies previous attributes that applied to the file into the new gitattributes line so disjoint attributes continue to work, but past filter, merge, and diff attributes are overridden. We could probably add a warning if we are overwriting some old attribute

[blester125]

At the bottom of https://git-scm.com/docs/gitattributes there is an example that seems to suggest that git attributes also cascade across lines (i.e. you can set one attr in a line and then a disjoint set in another) I don't think we handle this perfectly so we might need to revisit and add lots of testing. It might also make sense to use git-check-attr to see what is on a file and create a new entry based on that instead of making sure we match their parsing logic perfectly?