In addition to re-normalizing the line endings, we could also start
enforcing coding standards, e.g. tabs converted to spaces standard via
gitconfig/gitattribute filters. Git allows you to define filters in your
.git/config or ~/.gitconfig file and specifying their use in
.gitattributes, e.g. in .gitconfig:
# Convert tabs to 4 spaces (uses Linux expand/unexpand commands, so not
cross-platform)
[filter "tabspace"]
smudge = unexpand --tabs=4 --first-only
clean = expand --tabs=4 --initial
Then in .gitattributes:
# Code formats
*.c text filter=tabspace
*.cpp text filter=tabspace
*.h text filter=tabspace
*.hpp text filter=tabspace
*.ipp text filter=tabspace
*.tpp text filter=tabspace
On a related topic, what is the svneol .gitattribute being used in the
.gitattributes file do? I couldn't find it documented (I discovered the
filter attribute while searching for the svneol attribute). Also, the mime
type specified in a # comment following some attribute rule specification
doesn't seem to be a supported syntax, i.e. the '#' has to be in the first
column.
Michael
On Wed, Nov 27, 2013 at 3:02 PM, Gavin Lambert
On 28/11/2013 05:17, Quoth Dave Abrahams:
Another possibility might be to explicitly mark all text files in
.gitattributes with eol=lf and then run the conversion; I think that would fix the repository blobs,
What goes into .gitattributes has no effect on the content of blobs in the repository.
Sorry, when I wrote that I was envisaging the conversion process doing the equivalent of an SVN checkout and then git add/commit. (And git commit does take the attributes into account for eol conversion.)
Since apparently it doesn't work like that, just ignore that suggestion.
I still think that we need to renormalise the line endings though. Whether that's done as a reconversion (fixing history) or just as an extra commit (fixing current heads), that's up to you guys. ;)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost