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

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

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

quoted text
> 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



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html