Yes. <div><br></div><div>As you pointed out, that global is the default, so you don't need to do nothing</div><div>Just check that nothing comes out from</div><div><br></div><div>git config --global core.autocrlf</div>
<div><br></div><div>BUT FOR WINDOWS users:</div><div><br></div><div><a href="http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/">http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/</a></div>
<div><ul style="padding:0px;margin:0px 0px 15px 30px;line-height:18px;color:rgb(34,34,34);font-family:'Lucida Grande','Lucida Sans Unicode',Helvetica,Arial,sans-serif;font-size:13px"><li style="background-color:rgb(255,255,255);padding:0px;margin:0px 0px 5px">
<p style="padding:0px;margin:0px 0px 15px;line-height:1.5"><code style="padding:0px;margin:0px">core.autocrlf = false</code> – This is the default, but most people are <a href="http://help.github.com/line-endings/" style="padding:0px;margin:0px;color:rgb(0,68,119)">encouraged</a> 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 <code style="padding:0px;margin:0px">LF</code> or <code style="padding:0px;margin:0px">CRLF</code> or <code style="padding:0px;margin:0px">CR</code> 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 <code style="padding:0px;margin:0px">CRLF</code> 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.</p>
</li><li style="padding:0px;margin:0px 0px 5px"><p style="padding:0px;margin:0px 0px 15px;line-height:1.5"><code style="padding:0px;margin:0px;background-color:rgb(255,255,0)">core.autocrlf = true</code><span style="background-color:rgb(255,255,255)"> – This means that Git will process all </span><em style="background-color:rgb(255,255,255);padding:0px;margin:0px">text</em><span style="background-color:rgb(255,255,255)"> files and make sure that </span><code style="background-color:rgb(255,255,255);padding:0px;margin:0px">CRLF</code><span style="background-color:rgb(255,255,255)"> is replaced with </span><code style="background-color:rgb(255,255,255);padding:0px;margin:0px">LF</code><span style="background-color:rgb(255,255,255)"> when writing that file to the object database and turn all </span><code style="background-color:rgb(255,255,255);padding:0px;margin:0px">LF</code><span style="background-color:rgb(255,255,255)"> back into </span><code style="background-color:rgb(255,255,255);padding:0px;margin:0px">CRLF</code><span style="background-color:rgb(255,255,255)"> when writing out into the working directory. </span><span style="background-color:rgb(255,255,0)">This is the recommended setting on Windows because it ensures that your repository can be used on other platforms while retaining <code style="padding:0px;margin:0px">CRLF</code> in your working directory. [BUT SEE MY NOTE BELOW]</span></p>
</li><li style="background-color:rgb(255,255,255);padding:0px;margin:0px 0px 5px"><p style="padding:0px;margin:0px 0px 15px;line-height:1.5"><code style="padding:0px;margin:0px">core.autocrlf = input</code> – This means that Git will process all <em style="padding:0px;margin:0px">text</em> files and make sure that <code style="padding:0px;margin:0px">CRLF</code> is replaced with <code style="padding:0px;margin:0px">LF</code> when writing that file to the object database. It will <strong style="padding:0px;margin:0px">not</strong>, 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 <code style="padding:0px;margin:0px">LF</code>s to denote the end of line. This setting is generally used on Unix/Linux/OS X to prevent <code style="padding:0px;margin:0px">CRLF</code>s from getting written into the repository. The idea being that if you pasted code from a web browser and accidentally got <code style="padding:0px;margin:0px">CRLF</code>s into one of your files, Git would make sure they were replaced with <code style="padding:0px;margin:0px">LF</code>s when you wrote to the object database.</p>
</li></ul></div><div><br></div><div>That is, this problem is a two-fold one.</div><div><br></div><div>- One thing is to specify what files will have LF in the repo (problem A)</div><div>- One thing is to specify what files will have native EOL in the working directory (problem B)</div>
<div><br></div><div>The </div><div><br></div><div>* text=auto</div><div><br></div><div>in .gitattributes (or a more elaborated list, as in your email) ensures the repo LF in text files. (solves problem A, consistency in repo)</div>
<div><br></div><div>The global core.autocrlf is for your machine (solves problem B, easy to use in your machine)</div><div><br></div><div>If you work on Windows, you don't need core.autocrlf in true, IF YOU USE NOTEPAD++ or other "smart" editor.</div>
<div><br></div><div>I just did the steps of</div><div><a href="http://schacon.github.com/git/gitattributes.html">http://schacon.github.com/git/gitattributes.html</a></div><div>Section: <h4 id="_end_of_line_conversion" style="color:rgb(82,123,189);font-family:sans-serif;margin-top:1.2em;margin-bottom:0.5em;line-height:1.3;font-size:medium">
End-of-line conversion</h4><div>see Note:</div><div><div class="admonitionblock" style="margin-top:2.5em;margin-bottom:2.5em;font-family:serif;font-size:medium"><table><tbody><tr><td class="icon" style="vertical-align:top;font-size:1.1em;font-weight:bold;text-decoration:underline;color:rgb(82,123,189);padding-right:0.5em">
<div class="title" style="font-family:sans-serif;margin-top:0em;margin-bottom:0.5em">Note</div></td><td class="content" style="padding-left:0.5em;border-left-width:2px;border-left-style:solid;border-left-color:silver">When <tt style="color:navy">text=auto</tt> 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:</td>
</tr></tbody></table></div><div class="listingblock" style="margin-top:1.5em;margin-bottom:1.5em;font-family:serif;font-size:medium"><div class="content" style="padding:0.5em;border:1px solid silver;background-color:rgb(244,244,244);background-repeat:initial initial">
<pre style="padding:0px;margin-top:0px;margin-bottom:0px"><tt style="color:navy">$ 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"</tt></pre></div></div></div>in one of my repos, and all is OK.</div><div><br></div><div>Angel "Java" Lopez</div><div><br><div class="gmail_quote">
On Tue, Jan 22, 2013 at 7:49 AM, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok to summarize<br>
<br>
<br>
You suggest to have<br>
git config --global core.autocrlf false<br>
<br>
(= the default)<br>
<br>
and have an individual<br>
.gitattributes<br>
<br>
file per repository?<br>
<br>
With at least<br>
<br>
*.st text<br>
*.md text<br>
*.png binary<br>
*.jpg binary<br>
*.mcz binary<br>
<br>
Note aside: I think it is useful for porting to store the original<br>
Monticello *.mcz files (from Squeaksource etc) along with the port.<br>
This safes time for doing code reviews.<br>
<br>
--Hannes<br>
<div class="HOEnZb"><div class="h5"><br>
On 1/22/13, Angel Java Lopez <<a href="mailto:ajlopez2000@gmail.com">ajlopez2000@gmail.com</a>> wrote:<br>
> The problem with global settings, is when you start to work on different<br>
> projects, your global settings could interfere with the expected work on<br>
> that projects.<br>
><br>
> So, I would go for local settings per project. And maybe, explicit<br>
> specifying the text files:<br>
><br>
> *.st text<br>
> *.md text<br>
> ...<br>
> *.png binary<br>
> ...<br>
><br>
> Hahaha!... I'm ot a GitHub expert, but a daily user, yes<br>
><br>
> Angel "ACommitToGitHubADayKeepsTheDoctorAway" Lopez<br>
><br>
> On Tue, Jan 22, 2013 at 7:24 AM, H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>> wrote:<br>
><br>
>> Thank you Angel, as our github expert in residence for these links<br>
>> about line end problems with github.<br>
>><br>
>> The reference<br>
>> <a href="http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/" target="_blank">http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/</a> gives<br>
>><br>
>> "Git’s primary solution to all this is to specify that LF is the best<br>
>> way to store line endings for text files in a Git repository’s object<br>
>> database. "<br>
>><br>
>> and<br>
>><br>
>> "<br>
>> core.autocrlf = false<br>
>><br>
>> – This is the default, but most people are encouraged to change this<br>
>> immediately. The result of using false is that Git doesn’t ever mess<br>
>> with line endings on your file<br>
>> "<br>
>><br>
>><br>
>><br>
>> I use Windows 7 with a git bash shell.<br>
>><br>
>> I had not done yet a change so I do now<br>
>><br>
>> git config --global core.autocrlf true<br>
>><br>
>> on my MINGW32 git bash shell , right?<br>
>><br>
>> Is this enough for Cuis/Squeak/Pharo use? Or do I need to go for a<br>
>> .gitattributes file?<br>
>><br>
>> Kind regards<br>
>> Hannes<br>
>><br>
>> On 1/22/13, Angel Java Lopez <<a href="mailto:ajlopez2000@gmail.com">ajlopez2000@gmail.com</a>> wrote:<br>
>> > Ah! This is a discussion about text files in repo, no text file<br>
>> processing<br>
>> > in Smalltalk.<br>
>> ><br>
>> > Then:<br>
>> ><br>
>> <a href="http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git" target="_blank">http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git</a><br>
>> > <a href="https://help.github.com/articles/dealing-with-line-endings" target="_blank">https://help.github.com/articles/dealing-with-line-endings</a><br>
>> > and specially<br>
>> > <a href="http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/" target="_blank">http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/</a><br>
>> ><br>
>> > Angel "GitHub" Lopez ;-)<br>
>> ><br>
>> > On Tue, Jan 22, 2013 at 5:36 AM, H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> >> Hello Juan<br>
>> >><br>
>> >> On 1/22/13, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br>
>> >> > Germán Arduino wrote:<br>
>> >> ..<br>
>> >> >><br>
>> >> >> Just noticed also that in Windows I have also the bad formatting<br>
>> >> >> with<br>
>> >> >> the cr/lf as if they were not converted.<br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> >> > I use Cuis on Mac and Windows all the time. I never had any issue<br>
>> >> > with<br>
>> >> > cr/lf. Maybe you're editing files in notepad.exe?<br>
>> >><br>
>> >> Yes, I do that sometimes, e.g. to edit README.md files. I realize that<br>
>> >> after some editing operations lines are double spaced.<br>
>> >><br>
>> >><br>
>> >> Or transferring them<br>
>> >> > with a "smart" tool that thinks it must do conversions?<br>
>> >><br>
>> >> An alternative tool I use is Notepad++<br>
>> >> <a href="http://www.notepad-plus-plus.org/" target="_blank">http://www.notepad-plus-plus.org/</a><br>
>> >><br>
>> >><br>
>> >> In any case,<br>
>> >> > prepare a list of steps to reproduce the problems you see, and I'll<br>
>> >> > take<br>
>> >> > a look (as usual).<br>
>> >><br>
>> >><br>
>> >> Yes<br>
>> >><br>
>> >> > Cheers,<br>
>> >> > Juan Vuletich<br>
>> >><br>
>> >><br>
>> >> Regards<br>
>> >> Hannes Hirzel<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Cuis mailing list<br>
>> >> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>> >> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>> >><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> Cuis mailing list<br>
>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>><br>
><br>
<br>
_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
</div></div></blockquote></div><br></div>