Hi,
On Tue, 22 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> > When a file's crlf attribute is explicitely set, it does not make
> > sense to ignore it, just because the config variable core.autocrlf has
> > not been set.
>
> I am not sure if I agree with that reasoning.
>
> Attribute defines what each path is. Is it a text file, is it a binary?
> The nature of the contents does not change between people on POSIX and
> Windows, and that is why it is described in .gitattributes and cloned
> across repositories.
>
> On the other hand, the configuration defines what to do with contents with
> various attributes in this particular repository. Do I want to see a text
> file checked out with CRLF endings, or LF?
Actually, I now see that I expressed myself badly. Extremely badly.
The whole issue is about _check in_, as can be seen from the test case I
provided.
And I think it is even a bug in crlf handling, as gitattributes.txt has
this to say about crlf=input:
This is similar to setting the attribute to `true`, but
also forces git to act as if `core.autocrlf` is set to
`input` for the path.
It suggests to this coder that core.autocrlf is not even looked at when
crlf=input.
> So it is perfectly valid and normal for a cross-platform minded project
> to use the crlf atttribute to say "These files are text" and expect them
> to be checked out with LF endings on POSIX while making sure they are
> checked out with CRLF on Windows. Adding CR at the end of line for such
> files on POSIX systems is positively a wrong thing to do in such a case.
>
> Projects like the kernel that originate from LF side of the world may not
> bother marking things as such, though.
I fully agree.
However, if you want to avoid CRs to _enter_ the repository, when you have
a lot of binary files tracked, you _do_ want to force all repositories to
crlf=input.
Now, if you look at the patch, you will see that it _only_ touches
crlf_to_git(), but not only for crlf=input, but also for crlf=true.
I maintain that this respects the law of least surprise, namely that if
you set the attribute crlf=true, and some person forgets to set
core.autocrlf=true, at _check in_ CRs are stripped, but at _check out_, no
CR is added (as the person did not ask for core.autocrlf, but that should
not punish all the others who do not want to have CRs in the repository).
But yes, the commit message, and the oneline in particular are severely
lacking.
Tomorrow,
Dscho
--
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
