Re: CRLF problems with Git on Win32

From: Christer Weinigel <christer@weinigel.se>
Date: Jan 11, 2008, 19:53 UTC
Message-ID: <20080111205349.00ebccd9@weinigel.se>
In-Reply-To: <alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org>

On Fri, 11 Jan 2008 10:10:00 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 18 quoted lines

> 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.

That's how I work all the time. My Linux box is a Samba server where I check things out from perforce (with the "share" settings for end of line which means that text files are checked out with LF only and CRLF is converted to LF on checkin). Having the data on the Linux box is nice since I can have all the nice Unix tools such as sed, find, grep, and they run fast on a native Linux system, which is not true about cygwin on Windows.

Show 5 quoted lines

> 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.

We're working in a mixed environment, and even though I do most of my development on Linux I usually want to make sure that things build in Visual Studio before I check in, so the easiest thing to do is to point Visual Studio at the files on the Samba share. Same thing when using Altera's tools to do CPLD development, I run the Altera tools on Windows (their free version is Windows only) but all the files are on the Linux box. My tools that take the SVF file (the "binary image" for the CPLD) and program the CPLD all run under Linux though.

A lot of my colleagues have Windows on the desktop, and when they develop on Linux they usually edit the files locally using the Samba share, and then they have a Putty (ssh) connected to the Linux box where they build and test the software.

So the shared scenario is actually a very common one for us.

Show 6 quoted lines

> 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!

Actually I seldom have any problems with CRLF at all. Sometimes the Xilinx or Altera editors will insert some stray CRLFs in some files, but all the tools I use seem to tolerate that. And as soon as I check in the CRLFs disappear anyway. We just have to make sure to turn on the "share" setting in our Perforce views and everything just works.

  /Christer