tboegi@xxxxxx writes: > From: Torsten Bögershausen <tboegi@xxxxxx> > > A follow-up after a discussion how to fix the flaky execution > of t0025, gmane/$284352. > ... > The new handling makes sure that after running "git reset --hard". > "git status" reports the working tree as clean regarding CRLF > conversion. It makes sure that the Git-internal eol conversion is > doing roundtrip. A user can still write an external smudge/clean > filter outside Git, which doesn't do a roundtrip and the working > directory is not clean. If the project (not Git itself, but I am talking about any project used by real people) declares that the blobs in the history must be using LF endings (perhaps it wants to be protable across two worlds) by telling the users to set configurations so that "git add" would do the crlf-to-lf conversion, why is it a good idea to bend over backwards to _hide_ the fact that the index records something that contradicts with the project policy expressed by the end-user configuration? If the project wants to standardize on CRLF endings in the recorded history and some users use configurations and filters to use LF ending in their working tree, the same argument applies. If they by mistake or whatever adds blobs with LF line ending, that also should be shown as a change. I would understand if the "fix" were to make sure that the working tree files are dirty after "git reset --hard". If you "git add" the files from the working tree and make a commit from such a state, you will be changing the path in the commited history, so by definition the working tree should be reported as dirty, shouldn't it? I started to suspect that the flaky test in t0025 is not worth addressing for some time ago (iow, it is testing and expecting some fixed result where we should just declare "the behaviour is undefined if you did so"), and especially if the best we can do is to treat line-ending conversion something so special, it does not sound like we are going in the right direction. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html