* Re: Re: Git for Windows and line endings
2012-10-19 14:39 ` [msysGit] " Chris B
@ 2012-10-19 17:22 ` Junio C Hamano
2012-10-19 20:59 ` Jeff King
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2012-10-19 17:22 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
Chris B <chris.blaszczynski@gmail.com> writes:
> - If there was SO MUCH thought into this, then it was too much...
I do not have much to add to what area experts already said on bits
specific to Git for Windows, but on just this part:
> - Our builds were not breaking, it was production due to deployment
> model utilizing Git. What if there was a process to extract from Git
> and then distribute?
Do you mean something like "git archive"? Or do you have something
else in mind?
> - Developers are not expecting revision control system to make changes
> to files they commit.
But isn't there a distinction between the logical content and its
physical representation? In source code (that is what developers
use a source code management system for), especially those of
cross-platform projects, the logical lines end with LF and physical
lines end with whatever is convenient on the platform of each
participant of the project. There needs a way to convert between
the two.
It does not sound fair to call it a crime if the port to a platform,
whose users (at least the majority of them) expect the latter to be
CRLF, chose to default to that to help the majority, as long as
there are ways for the minority power users to choose to use LF in
the physical representation on their working trees.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Re: Git for Windows and line endings
2012-10-19 14:39 ` [msysGit] " Chris B
2012-10-19 17:22 ` Junio C Hamano
@ 2012-10-19 20:59 ` Jeff King
2012-10-19 21:53 ` [msysGit] " John Szakmeister
2012-11-04 12:37 ` Raja R Harinath
3 siblings, 0 replies; 8+ messages in thread
From: Jeff King @ 2012-10-19 20:59 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote:
> I would like to point out:
> - Git on Linux does not mess around with line endings. I can create
> and edit a file in either line ending on Linux and commit and still
> have it untouched.
> - Git on Windows via Cygwin also does not mess around.
> - If those flavors of Git don't mess around, why should msysgit do it?
Most platforms (i.e., the userspace of most unix-y distributions) do not
mess around with line endings, either, so it is easy to have a sane
default there. I think the Cygwin build just followed that existing
defaults.
But msysgit's behavior was directly responding to user complaints. And
there were a lot of them. I do not use Windows myself, so I have only
the perspective of reading the list discussions. And that only what
bleeds onto the git@vger list, not the msysgit list.
Searching for "crlf" on the list yields over 2300 messages, many of
which discuss specific problems people are having without CRLF support.
I do not think any decision in the open source world is final, and
correcting a wrong decision from the past should always be an option.
But I do not think it is constructive to say "your decision is wrong"
without responding to the arguments that led to that decision. All I see
in your email is "your default is not my preference" without responding
to the discussion and perspectives of others through the years.
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
Again, I do not use Windows, so my anecdotes are purely culled from the
list. But people have mentioned that Visual Studio is bad for writing
our CRLFs for files which already have LFs. This makes diffs unreadable,
and gives merges, rebases and cherry-picks lots of spurious conflicts.
> - If there was SO MUCH thought into this, then it was too much; it was
> the wrong thought. There should not have been much at all, and just
> allow Git to do what it does: store things *exactly* as you put it in.
> Allow the clients to worry about things like line endings should they
> have the need to worry about it. I'm not seeing how the revision
> system has any business making alterations to things one commits into
> it.
One of the problems is that people do not realize the issue until they
have built a lot of history with CRLFs or mixed line endings (which they
might not even realize until the project starts being used by somebody
with a different editor or platform), and then they have a very painful
flag day turning on these options and normalizing the repository.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [msysGit] Re: Git for Windows and line endings
2012-10-19 14:39 ` [msysGit] " Chris B
2012-10-19 17:22 ` Junio C Hamano
2012-10-19 20:59 ` Jeff King
@ 2012-10-19 21:53 ` John Szakmeister
2012-11-04 12:37 ` Raja R Harinath
3 siblings, 0 replies; 8+ messages in thread
From: John Szakmeister @ 2012-10-19 21:53 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
On Fri, Oct 19, 2012 at 10:39 AM, Chris B <chris.blaszczynski@gmail.com> wrote:
[snip]
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
That's simply not a true, across the board statement. I really wish
it was, because I find the issue troublesome as well. Unfortunately,
there are still plenty of applications that don't cope with mixed line
endings very well. We have a backend that targets several platforms,
and the Windows toolchain is quite keen on having CRLF endings, but we
like LF under Linux, and others.
I also wish that no developers were using Notepad either. Any time
I've run across it, I've tried to point folks at much more capable
environments... but that only has moderate success. Of course, it's
even worse these days because Notepad puts a BOM at the front of the
file, making Git think it's a binary file.
One thing I do wish is that I didn't have to do the song and dance to
convert all the files when I set gitattributes:
$ echo "* text=auto" >>.gitattributes
$ rm .git/index # Remove the index to force git to
$ git reset # re-scan the working directory
$ git status # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"
One thing that I like about Subversion was that when you set
svn:eol-style, it took.
-John
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [msysGit] Re: Git for Windows and line endings
2012-10-19 14:39 ` [msysGit] " Chris B
` (2 preceding siblings ...)
2012-10-19 21:53 ` [msysGit] " John Szakmeister
@ 2012-11-04 12:37 ` Raja R Harinath
3 siblings, 0 replies; 8+ messages in thread
From: Raja R Harinath @ 2012-11-04 12:37 UTC (permalink / raw)
To: git; +Cc: msysgit
Hi,
Chris B <chris.blaszczynski@gmail.com> writes:
[snip]
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
> - VIM also handles Windows line endings just fine as well. I just
> tested it on a Linux machine. Maybe old version? (pure VI is not even
> on this machine but hard to press these days it can't handle it.)
> - The files in .git folder are in UNIX format anyway, so why are those
> not also included in line ending changes? Isn't is because there is a
> Windows app (msysgit) running on Windows that expects the UNIX line
> ending? So in the same manor, someone might have a Windows system
> using some Cygwin components perhaps, or a Windows C program possibly
> poorly written or just old, that demand some text files to be left
> alone in the format we saved it.
There are several subtleties in LF handling with mixed systems. Here's
my write-up in:
https://github.com/mono/mono/blob/master/.gitattributes
for an example set of trade-offs. Quoting in full since it's fairly short.
- Hari
# CRLF Handling
# -------------
#
# The ideal situation would be to do no EOL normalization. Each file
# would have a default EOL, and tools on Windows and Linux would handle
# both EOL formats.
#
# We're not in the ideal world. A popular editor on Windows (possibly
# Visual Studio) silently introduces EOL corruption -- it displays an
# LF-file normally, but any newly added lines have CRLF. On Linux,
# Emacs and versions of VI handle LF-files and CRLF-files properly.
# However, emacs doesn't like files with both LF and CRLF EOLs. Editing
# the file without additional action will increase the EOL corruption
# in the file.
#
# Another vector for mixed EOLs is scripts. We mostly don't have scripts
# that add new lines -- so we rarely see this. However, one major event
# in the tree was the addition of copyright headers using a script. That
# script introduced EOL corruption.
#
# Any automated EOL normalization of files already in the repository will
# cause difficulties in traversing histories, assigning blame, etc. So, we
# don't want to change what's in the repository significantly, even if it
# causes trouble.
#
# What we do now:
#
# a) we ensure that there's no further corruption of LF-files. So, we use
# git's 'crlf' attribute on those files to ensure that things are fine
# when we work on Windows. We could use 'crlf=input', but it doesn't buy
# us much -- we might as well be working with consistent EOLs for files in
# working directories as well as in the repository
#
# b) if the file already of CRLFs, we don't do any normalization. We use '-crlf'
# so that git doesn't do any EOL-conversion of the file. As I said, this
# is mostly harmless on Linux. We can't mark these files as 'crlf' or use
# the new (git 1.7.2) 'eol=crlf' attribute, since it changes the contents
# _inside_ the repository [1], and hence makes history traversal annoying.
# So, we live with occasional EOL corruption.
#
# c) We can handle mixed-EOL files on a case-by-case basis, converting them to
# LF- or CRLF-files based on which causes fewer lines to change
#
# d) We try to ensure no further headaches, by declaring EOL normalization on
# code files, and Unix-flavoured files, like shell-scripts, makefiles, etc.
#
# [1] GIT use LFs as the normalized internal representation.
^ permalink raw reply [flat|nested] 8+ messages in thread