[Cuis] About cr/lf issues in MSWindows
Angel Java Lopez
ajlopez2000 at gmail.com
Tue Jan 22 05:31:29 CST 2013
Two discoveries:
1) For Windows users, setting
git config --global core.autocrlf true
could be replace by
git config core.autocrlf true
IN THE REPO DIRECTORY. That is, you can set it by repo. I have customers
that requires core.autocrlf false to work with their repos, so it could be
set by repo, overridden any global setting.
2) Even using nodepad++ and other "smart" directories, and using
core.autocrlf false (no conversion), your files will have LF in your
working directory, if they have LF in the repo, All it's OK, but I had
problems with some tools, ie. Node.js debugger/exceptions: in Windows, an
exception shows the line number/character position, and if the source code
is with LF no CRLF, then message could say:
Line 1, Position 1345
Instead of
Line 20, Position 8
On Tue, Jan 22, 2013 at 8:02 AM, Angel Java Lopez <ajlopez2000 at gmail.com>wrote:
> Yes.
>
> As you pointed out, that global is the default, so you don't need to do
> nothing
> Just check that nothing comes out from
>
> git config --global core.autocrlf
>
> BUT FOR WINDOWS users:
>
> http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/
>
> -
>
> core.autocrlf = false – This is the default, but most people are
> encouraged <http://help.github.com/line-endings/> to change this
> immediately. The result of using false is that Git doesn’t ever mess with
> line endings on your file. You can check in files with LF or CRLF or CR or
> some random mix of those three and Git does not care. This can make diffs
> harder to read and merges more difficult. Most people working in a
> Unix/Linux world use this value because they don’t have CRLF problems
> and they don’t need Git to be doing extra work whenever files are written
> to the object database or written out into the working directory.
> -
>
> core.autocrlf = true – This means that Git will process all *text* files
> and make sure that CRLF is replaced with LF when writing that file to
> the object database and turn all LF back into CRLF when writing out
> into the working directory. This is the recommended setting on Windows
> because it ensures that your repository can be used on other platforms
> while retaining CRLF in your working directory. [BUT SEE MY NOTE BELOW]
> -
>
> core.autocrlf = input – This means that Git will process all *text* files
> and make sure that CRLF is replaced with LF when writing that file to
> the object database. It will *not*, however, do the reverse. When you
> read files back out of the object database and write them into the working
> directory they will still have LFs to denote the end of line. This
> setting is generally used on Unix/Linux/OS X to prevent CRLFs from
> getting written into the repository. The idea being that if you pasted code
> from a web browser and accidentally got CRLFs into one of your files,
> Git would make sure they were replaced with LFs when you wrote to the
> object database.
>
>
> That is, this problem is a two-fold one.
>
> - One thing is to specify what files will have LF in the repo (problem A)
> - One thing is to specify what files will have native EOL in the working
> directory (problem B)
>
> The
>
> * text=auto
>
> in .gitattributes (or a more elaborated list, as in your email) ensures
> the repo LF in text files. (solves problem A, consistency in repo)
>
> The global core.autocrlf is for your machine (solves problem B, easy to
> use in your machine)
>
> If you work on Windows, you don't need core.autocrlf in true, IF YOU USE
> NOTEPAD++ or other "smart" editor.
>
> I just did the steps of
> http://schacon.github.com/git/gitattributes.html
> Section: End-of-line conversion
> see Note:
> Note
> When text=auto normalization is enabled in an existing repository, any
> text files containing CRLFs should be normalized. If they are not they will
> be normalized the next time someone tries to change them, causing
> unfortunate misattribution. From a clean working directory:
>
> $ 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"
>
> in one of my repos, and all is OK.
>
> Angel "Java" Lopez
>
> On Tue, Jan 22, 2013 at 7:49 AM, H. Hirzel <hannes.hirzel at gmail.com>wrote:
>
>> Ok to summarize
>>
>>
>> You suggest to have
>> git config --global core.autocrlf false
>>
>> (= the default)
>>
>> and have an individual
>> .gitattributes
>>
>> file per repository?
>>
>> With at least
>>
>> *.st text
>> *.md text
>> *.png binary
>> *.jpg binary
>> *.mcz binary
>>
>> Note aside: I think it is useful for porting to store the original
>> Monticello *.mcz files (from Squeaksource etc) along with the port.
>> This safes time for doing code reviews.
>>
>> --Hannes
>>
>> On 1/22/13, Angel Java Lopez <ajlopez2000 at gmail.com> wrote:
>> > The problem with global settings, is when you start to work on different
>> > projects, your global settings could interfere with the expected work on
>> > that projects.
>> >
>> > So, I would go for local settings per project. And maybe, explicit
>> > specifying the text files:
>> >
>> > *.st text
>> > *.md text
>> > ...
>> > *.png binary
>> > ...
>> >
>> > Hahaha!... I'm ot a GitHub expert, but a daily user, yes
>> >
>> > Angel "ACommitToGitHubADayKeepsTheDoctorAway" Lopez
>> >
>> > On Tue, Jan 22, 2013 at 7:24 AM, H. Hirzel <hannes.hirzel at gmail.com>
>> wrote:
>> >
>> >> Thank you Angel, as our github expert in residence for these links
>> >> about line end problems with github.
>> >>
>> >> The reference
>> >> http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/gives
>> >>
>> >> "Git’s primary solution to all this is to specify that LF is the best
>> >> way to store line endings for text files in a Git repository’s object
>> >> database. "
>> >>
>> >> and
>> >>
>> >> "
>> >> core.autocrlf = false
>> >>
>> >> – This is the default, but most people are encouraged to change this
>> >> immediately. The result of using false is that Git doesn’t ever mess
>> >> with line endings on your file
>> >> "
>> >>
>> >>
>> >>
>> >> I use Windows 7 with a git bash shell.
>> >>
>> >> I had not done yet a change so I do now
>> >>
>> >> git config --global core.autocrlf true
>> >>
>> >> on my MINGW32 git bash shell , right?
>> >>
>> >> Is this enough for Cuis/Squeak/Pharo use? Or do I need to go for a
>> >> .gitattributes file?
>> >>
>> >> Kind regards
>> >> Hannes
>> >>
>> >> On 1/22/13, Angel Java Lopez <ajlopez2000 at gmail.com> wrote:
>> >> > Ah! This is a discussion about text files in repo, no text file
>> >> processing
>> >> > in Smalltalk.
>> >> >
>> >> > Then:
>> >> >
>> >>
>> http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git
>> >> > https://help.github.com/articles/dealing-with-line-endings
>> >> > and specially
>> >> > http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/
>> >> >
>> >> > Angel "GitHub" Lopez ;-)
>> >> >
>> >> > On Tue, Jan 22, 2013 at 5:36 AM, H. Hirzel <hannes.hirzel at gmail.com>
>> >> wrote:
>> >> >
>> >> >> Hello Juan
>> >> >>
>> >> >> On 1/22/13, Juan Vuletich <juan at jvuletich.org> wrote:
>> >> >> > Germán Arduino wrote:
>> >> >> ..
>> >> >> >>
>> >> >> >> Just noticed also that in Windows I have also the bad formatting
>> >> >> >> with
>> >> >> >> the cr/lf as if they were not converted.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> > I use Cuis on Mac and Windows all the time. I never had any issue
>> >> >> > with
>> >> >> > cr/lf. Maybe you're editing files in notepad.exe?
>> >> >>
>> >> >> Yes, I do that sometimes, e.g. to edit README.md files. I realize
>> that
>> >> >> after some editing operations lines are double spaced.
>> >> >>
>> >> >>
>> >> >> Or transferring them
>> >> >> > with a "smart" tool that thinks it must do conversions?
>> >> >>
>> >> >> An alternative tool I use is Notepad++
>> >> >> http://www.notepad-plus-plus.org/
>> >> >>
>> >> >>
>> >> >> In any case,
>> >> >> > prepare a list of steps to reproduce the problems you see, and
>> I'll
>> >> >> > take
>> >> >> > a look (as usual).
>> >> >>
>> >> >>
>> >> >> Yes
>> >> >>
>> >> >> > Cheers,
>> >> >> > Juan Vuletich
>> >> >>
>> >> >>
>> >> >> Regards
>> >> >> Hannes Hirzel
>> >> >>
>> >> >> _______________________________________________
>> >> >> Cuis mailing list
>> >> >> Cuis at jvuletich.org
>> >> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> >> >>
>> >> >
>> >>
>> >> _______________________________________________
>> >> Cuis mailing list
>> >> Cuis at jvuletich.org
>> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> >>
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130122/c3dabb7d/attachment-0002.html>
More information about the Cuis
mailing list