[Cuis] About cr/lf issues in MSWindows
Angel Java Lopez
ajlopez2000 at gmail.com
Tue Jan 22 05:02:23 CST 2013
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/2c72e7fc/attachment-0002.html>
More information about the Cuis
mailing list