Taking advantage of the OneGit migration process, we are going to clean-up tabs and spaces in the whole history (hence keeping git-blame useful)
In order to do that, the repository are going through a git filter-branch process, typically something like git filter-branch --prune-empty --tag-name-filter cat --tree-filter 'git ls-files | clean_spaces -p 1 ' -- --all clean_spaces goal is to replace tab with the appropriate number of spaces (based on a 4 spaces indentation), and to eliminate trailing spaces. It is very critical that that tool be bug free. any bug could screw-up the history in subtitle or not subtitle ways. if this is not caught before the migration is done it could make fixing these problem very very hard... So, I call for as many pair of eyes as possible to make sure that the code of clean_spaces is sane. http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/clean_spaces/clean_spaces.c?id=c4ac6d490674f39b0175e6360e788cb576c122ba Thanks, Norbert Note: yes, there are leaks and hard coded buffer. They should be signaled as such in the source. This is not meant to be an all-purpose fool-proof tool, but it is meant to work as efficiently as possible within the constraint of the migration at hand. PS: Yes it is in C, and no, perl/bash/python/C++ are not an option. bear in mind that libs-core, for instance, as 68400+ commit to be processed, each commit is 8000+ files to be analyzed and 80MB of data to be parsed counting only cxx and hxx files. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
