Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH v1 7/7] convert.c: more safer crlf handling with text attribute

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:09:05

tboegi@web.de writes:
From: Torsten Bögershausen <redacted>

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help