Re: CRLF problems with Git on Win32

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jan 11, 2008, at 7:10 PM, Linus Torvalds wrote:



On Fri, 11 Jan 2008, Steffen Prohaska wrote:

Ah sorry, I misunderstood you in [1].  I thought your last point
"Mixed Windows usage" meant what I have in mind:  A user working
in a mixed Windows/Unix environment who creates a file using
Windows tools and commits it in the Unix environment.  In this
case the CRLF file will be transferred from Windows to Unix
without git being involved.  The right thing for git on Unix is
to remove CRLF during a commit but still write only LF during
check out.  So autocrlf=input is the right choice.

Oh, ok, I didn't realize.

But yes, if you use a network share across windows and Unixand actually *share* the working tree over it, then yes, you'd want "autocrlf=input" on
the unix side.

However, I think that falls under the "0.1%" case, not the "99.9%" case.

I realize that people probably do that more often with centralized
systems, but with a distributed thing, it probably makes a *ton* more
sense to have separate trees. But I could kind of see having a shared
development directory and accessing it from different types of machines
too.

It just happens yesterday that I copied a file from Unix to Windows
(lucky I am ;) for a quite simple reason.  I fetched and merged and
realized that another developer forgot to check in a new file. He
had already left.  So I just looked into his workspace and copied
the file.  This has nothing to do with centralized system or not.
We're just working in a mixed OS environment with shared filesystems.

I didn't even think about the line endings in this situation because
everything just worked.  Actually I like the idea that I do not
need to think about the endings because git will care about them.
Actually many other tools work well with CRLF.  For example, vi
just displays [dos] in its status bar; but besides this everything
is just fine.


I'd also bet that crlf behavior of git itself will be the *least* of your
problems in that situation. You'd have all the *other* tools to worry
about, and would probably be very aware indeed of any CRLF issues. So at
that point, the "automatic" or default behaviour is probably not a big
deal, because everything _else_ you do likely needs special effort too!

I don't think so. In the setting I described above, the questions I receive
are not about the other tools but about git.  I already started to teach
everyone the new "autocrlf=input" policy to avoid these questions. I don't
care that much about potential file corruption (though I'd feel more
comfortable if I knew git would have stronger guarantees). During the next
checkout on Windows file corruption would happen anyway.

	Steffen

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux