Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> IMHO this is really not good. Better do it in the global /etc/gitconfig
> we install _anyway_ (it says core.symlinks=false).
That sounds like a perfect place for a per-platform tweak like
this than in the code, but I wonder if peoples' scripts have
valid use case of GIT_CONFIG to bypass it (git-svn's use of the
variable to access its private data seems to be Ok).
>> Perhaps we can do something similar to core.filemode? Create a file
>> that we would need to create anyway in "text" mode, and read it back in
>> "binary" mode to see what stdio did?
>
> The problem is that MinGW behaves sanely, i.e. it does not output CRLF but
> only LF.
Won't that behaviour be viewed rather as "insanely" from
majority of Windows users?
> But maybe I am the minority here, and we really should default to
> crlf=true on Windows, and provide a way to unset that.
>
> My preference would be to have Peff's -c switch to clone, but
> _additionally_ a way to force a full re-checkout of files (for example
> after "git config core.crlf false").
I have been hoping a better (simpler to use, and somewhat more
importantly harder to misuse by being not overly flexible) way
than that "clone -c" solution, but that is an implementation
issue (I think the tweak rather belongs to init than clone
anyway, and the point of "-c" is that it is not easy to tweak
the way "init" that is used by "clone" behaves).
Switching core.crlf (or gitattributes to change filter -- in
general, "affecting the way convert_to_working_tree() and
convert_to_git() works") can be done for two opposite reasons.
(1) repository is correct and checkout is wrong. This wants
re-checkout.
(2) repository records in a wrong convention by mistake and
needs to be fixed. Re-checkout is obviously a wrong thing
to do, and re-checkin (not necessarily commit, but updating
the index) is necessary.
We need both.
-
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
