
On Thu, Nov 28, 2013 at 9:18 PM, Niall Douglas
On 28 Nov 2013 at 10:14, Beman Dawes wrote:
We can get this right by setting the gitattributes files to something appropriate and normalizing the repos (most repos are actually fine already). But there will be issues with checking out old versions. There are a few approaches to fixing this, but Beman isn't keen on delaying conversion further. Most people don't use old versions so it won't be a big problem, and if they wish to they can use the read only subversion repo, or normalise an older version themselves.
+1
In which case, we merge https://github.com/ryppl/Boost2Git/pull/42 and run one last conversion. All commits made to Boost since the SVN pre-commit hooks were added will be converted losslessly (i.e. last few years worth of commits). All commits preceding this where the EOLs do not match the file extension in the .gitattributes will be forced to the EOL specified in .gitattributes. For those test files in sandbox where deliberate mismatched EOLs are part of a test suite, those files will be irretrievably forced to correct EOL and therefore the unit tests will fail. Other similar loss of data may occur in files committed a long time ago.
In the case of a test data file with mismatched EOL you can add a .gitattributes file in the containing directory that tells git to treat the file as binary. So if this is the only issue regarding loss of data (I suspect it isn't) and there aren't too many of these files around, add the special case .gitattributes files. I'm generally in favor, though, in letting the history remain the history, i.e. that it accurately reflects the actual state at that time.
This is therefore the choice for the Boost community:
(i) Correct EOLs in all commits made last few years AND accept some data loss in prior (mostly ancient) commits
OR
(ii) mismatched EOLs during Boost checkout from git on Windows.
I'm not sure I understand the above. The bootstrap.bat file also shows up as a problem on the Linux side as a modified file on initial checkout, but since I don't use the file, it's just an annoyance on the Linux side.
OR
(iii) Someone in the Boost community comes up with something better which can be implemented before the permanent switch over next week.
Your choice, as Dave pointed out. We need consensus from this list on what to do.
Niall
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael