Thread (27 messages) 27 messages, 10 authors, 2016-08-13

Re: CRLF problems with Git on Win32

flat view

From: Christer Weinigel <hidden>
Date: 2016-06-15 22:44:04

Possibly related (same subject, not in this thread)

On Fri, 11 Jan 2008 10:10:00 -0800 (PST)
Linus Torvalds [off-list ref] wrote:
On Fri, 11 Jan 2008, Steffen Prohaska wrote:
quoted
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.  
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help