About cr/lf issues in MSWindows

Hello Juan

On 1/22/13, Juan Vuletich <[hidden email]> 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
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> Hello Juan
>>
>> On 1/22/13, Juan Vuletich <[hidden email]> 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
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>> >
>> >> Hello Juan
>> >>
>> >> On 1/22/13, Juan Vuletich <[hidden email]> 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
>> >> [hidden email]
>> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> >>
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>> >
>> >> Hello Juan
>> >>
>> >> On 1/22/13, Juan Vuletich <[hidden email]> 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
>> >> [hidden email]
>> >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> >>
>> >
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org