Git for Windows and line endings

Git for Windows and line endings

[Chris B]

Hi.. it is such a crime to have that default option of MSysGit mess
around with the line endings.

Caused us a lot of trouble.

There is no thought to the fact that it's possible the Git users are
not using Git the exact way the authors thought it would be used.
We have both Windows and Linux systems that have parts of their files
stored in Git repositories. And in addition to that, some Linux and
Windows Git clients. If everyone leaves the line endings alone,
everything works out just fine!

But messing with the line endings broke some things in production.

Re: Git for Windows and line endings

[Erik Faye-Lund]

On Fri, Oct 19, 2012 at 12:13 AM, Chris B <chris.blaszczynski@gmail.com> wrote:
> Hi.. it is such a crime to have that default option of MSysGit mess
> around with the line endings.

No it's not.

> There is no thought to the fact that it's possible the Git users are
> not using Git the exact way the authors thought it would be used.

Suggesting this is just insulting. A lot of thought was laid to ground
for the decision.

> We have both Windows and Linux systems that have parts of their files
> stored in Git repositories. And in addition to that, some Linux and
> Windows Git clients. If everyone leaves the line endings alone,
> everything works out just fine!

No, it will not. Notepad, which is the default text editor on Windows,
barfs on LF line-endings, and many vi installations does the same
thing on Unix-systems bards on CRLF line-endings. And so does a huge
amount of custom, less tested tools.

Thinking that "this works for me, so it must work for everyone" is
exactly the reason why this whole situation is a big mess. You are
only making it worse by not realizing the issues.

> But messing with the line endings broke some things in production.

I'm not even sure what you're trying to say with this e-mail other
than to blame us for your own problems. Stop making broken commits.
Clean up after you when you did by accident. And for the love of God,
stop blaming other people when you messed up.

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

Re: Re: Git for Windows and line endings

[Johannes Schindelin]

Hi,

On Fri, 19 Oct 2012, Erik Faye-Lund wrote:

> On Fri, Oct 19, 2012 at 12:13 AM, Chris B <chris.blaszczynski@gmail.com> wrote:
> > Hi.. it is such a crime to have that default option of MSysGit mess
> > around with the line endings.
> 
> No it's not.

Let's keep things professional. Eliciting emotions, especially negative
ones, traditionally makes it more unlikely to get what one asks for.

Also to clarify: as so many Open Source projects (but unlike Git itself),
msysGit is a purely volunteer-driven software. So naturally, contributors
have a lot more to say about the defaults than non-contributors [*1*].

Besides, there is a fantastic and very detailed page when running the
installer where the interested user can inform herself and change the
defaults to her likings very easily.

Therefore I consider this bug report -- insofar it was one -- as closed.

Ciao,
Johannes

Footnote [*1*]: And yes, the line endings default was changed from this
developer's preference to what it is now -- based on a discussion with
convincing arguments. Since msysGit is developed as an Open Source project
with a truly Open Source process, all of these discussions can be found in
the mailing list archives.


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

Re: [msysGit] Re: Git for Windows and line endings

[Chris B]

Hi.  I'm sorry about the tone of the email; I was writing it after
spending a lot of energy fixing things up and I should have taken some
time to breathe. I recognize this is likely not going to change and
even if I could jump in to contribute it wouldn't matter. I also
recognize that changing it now might cause more problems. I am hopeful
though.

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?

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

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

- 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? Sounds like it's simple and should work and there
are good advantages to this process to overcome speed of deployment
issues. That process is free to be either Linux or Windows, and to
distribute to either a Linux or Windows server. This process you may
consider a mistake, but the point is that Git is just storing things,
not worried about the process in which it is used.

- While there might be options to make the other flavors of Git mess
around with line endings, the default is to not touch it which is
critical. Because as you bring on developers you never know what they
selected during the installation, and you have to go back and have
them change it if they did something different.

- Developers are not expecting revision control system to make changes
to files they commit.

Re: Re: Git for Windows and line endings

[Junio C Hamano]

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

Re: Re: Git for Windows and line endings

[Jeff King]

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

Re: [msysGit] Re: Git for Windows and line endings

[John Szakmeister]

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

Re: [msysGit] Re: Git for Windows and line endings

[Raja R Harinath]

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.