On Feb 3, 2008, at 11:50 AM, Junio C Hamano wrote:

quoted text
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> CRLF conversion bears a slight chance of corrupting data.
>> ...
>> thing to do, while for binary file it corrupts data.
>
> The above 25-line or so are well written and deserve to be in
> the end user documentation somewhere, I think, to explain why it
> is a good idea to have these warnings to them..

For now, I propose to add it to the documentation of
core.safecrlf.  In the future a section on cross-platform
projects in the user manual would probably be the right place.
But the manual does not yet have such a section.


quoted text
>> This commit modifies git apply to fail even if safecrlf=warn,
>> because git apply writes its changes back to the work tree
>> immediately.  The user would not have a chance to backup the old
>> version of the file if only a warning was printed.
>
> I do not get this logic at all.
>
> The whole point of git-apply is to apply the patch.  If you say
> --whitespace=fix and some contents (say one of the testsuite
> files in our t/ directory) needed to keep trailing newline, you
> obviously are left with a broken result, and you would recover
> by checking it out from index or HEAD and reapply.  Why
> shouldn't the same principle hold here?

You are right.  All files should be committed before running
git apply and therefore the original files can be recovered by
git checkout.  Hmm ... so apply should either just warn or be
completely quiet as git blame is?  I think it should warn.

	Steffen

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html