GIT line ending settings

[Olle de Zwart]

I noticed some talk on twitter about the line endings and GIT. And from what I read I am getting the impression you are currently using the most painful/problematic way by setting core.autocrlf to false. Now I am no GIT expert but from what I read at http://help.github.com/dealing-with-lineendings/ and http://git.wiki.kernel.org/index.php/GitSvnComparison  “For users on Windows they should set core.autocrlf = true so that text files are automatically checked out with CRLF and checked in as LF.” I understand that the “correct” way would be to set core.autocrlf to true. Am I wrong on this and if so could you explain why?

 

 

Regards,

Olle

[Daniel Tabuenca]

Actually, in our experience it's been quite the opposite. When our
team first switched from svn to git we enabled autocrlf. We thought
it'd be good to maintain a repo with just LF line endings. This turned
out to be more trouble then was worth. When switching to crlf=true
(especially on an existing project) each contributor has to be careful
in how they clone and configure the project. And no matter how many
times we cleaned/cloned/stripped CRLFs we always seemed to at one
point or another run into a file that suffered from the "Everything
Changed" phenomenon due to line endings. I'm not saying it can't be
done, but to us it was really not worth the trouble.

With autocrlf=false you get exactly what you expect. If the file has
CRLF it is checked in with CRLF if the file has LF it is checked with
LF. There is no magic, no conversion, no confusion. Most editors deal
with CRLF or LF transparently and whether the file is stored with LF
or CRLF in the repo does not pose any tangible problems (unless you
are a purist that feels the repo must NEVER have any CRLFs).

Now, if you were working on a project that is primarily a unix project
(like say the linux kernel) and you are checking it out on a windows
machine, then maybe it would make sense to turn on atuocrlf, Even
then, probably a better solution is to simply set your editor to
always use LF line endings.

In the end we simply turned off autocrlf. Some of our files in our
solution have CRLF endings, some have LF endings. As long as no
individual file spontaneously changes back and forth from CRLF->LF
(which they shouldn't) this has absolutely zero impact on anything
(other than the few extra bytes per file on the repo). To us, this
autocrlf=false has not been painful or problematic in any way. It is
certainly easier than trying to enforce autocrlf policy at the time of
cloning by every contributor and dealing with the odd times where
autocrlf behaves weirdly and tells you your entire file has changed.

> --
> You received this message because you are subscribed to the Google Groups
> "Spark View Engine Dev" group.
> To post to this group, send email to spar...@googlegroups.com.
> To unsubscribe from this group, send email to
> spark-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
>

[Bill Barry]

Not related to Spark, but in our internal repository we have noticed that depending on some of the more obscure settings in windows/visual studio, files are sometimes converted from ascii to unicode resulting in a couple of bad characters at the beginning of the file if you look at the diffs (I think they are the code points that say the file is unicode). Thus far we have determined it has something to do with the Cyrillic settings some of our devs have configured to read emails from their relatives in Russia and the Ukraine. Occasionally we get an "everything changed" diff for these as well (and when this happens the web interface for our repos say that they cannot display the sources for the binary files).

Daniel Tabuenca wrote:

http://git.wiki.kernel.org/index.php/GitSvnComparison ��For users on Windows
they should set core.autocrlf = true so that text files are automatically
checked out with CRLF and checked in as LF.� I understand that the �correct�
way would be to set core.autocrlf to true. Am I wrong on this and if so
could you explain why?





Regards,

Olle

--
You received this message because you are subscribed to the Google Groups
"Spark View Engine Dev" group.
To post to this group, send email to spar...@googlegroups.com.
To unsubscribe from this group, send email to

[Louis DeJardin]

Yeah, Daniel's remarks are exactly in line with what I experienced when I migrated.

 

autocrlf is what you would use for a mixed development environment, where Windows clients would want to shift to CRLF in working copy and back to LF on commit.

 

Because Spark code is natively CRLF I turned off the setting to have the true file format in source control and avoid the whole round-tripping mess.

 

I noticed the other day MvcContrib has moved source control back onto Mercurial on Codeplex. That could be an option if the pull request and fork management is comparable to github. Could reduce the number of places you can find spark resources by one. :)

Daniel Tabuenca wrote:

http://git.wiki.kernel.org/index.php/GitSvnComparison  “For users on Windows
they should set core.autocrlf = true so that text files are automatically
checked out with CRLF and checked in as LF.” I understand that the “correct”
way would be to set core.autocrlf to true. Am I wrong on this and if so
could you explain why?





Regards,

Olle

--
You received this message because you are subscribed to the Google Groups
"Spark View Engine Dev" group.
To post to this group, send email to spar...@googlegroups.com.
To unsubscribe from this group, send email to

spark-dev+...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/spark-dev?hl=en.

    

[Christopher]

Apparently it's comparable, only branches are harder to delete. Tekpub has an intro to hg on codeplex video I believe. 

--

-Christopher Pelatari | http://bluefenix.net

[Bret Ferrier (runxc1)]

I watched Tekpubs free 30 minute video on HG and liked it. Mercurial
support for development on windows is a lot better than that of GIT
with TortoiseHG and the Visual Studio source control plugin. It
seems to make sense to me to use Mercurial at CodePlex so that there
is only one Code Repository

On Mar 13, 5:43 pm, Christopher <christop...@bluefenix.net> wrote:
> Apparently it's comparable, only branches are harder to delete. Tekpub  
> has an intro to hg on codeplex video I believe.
>
> --
> -Christopher Pelatari |http://bluefenix.net
>

> On Mar 13, 2010, at 3:48 AM, Louis DeJardin <louis.dejar...@gmail.com>  

> wrote:
>
>
>
> > Yeah, Daniel's remarks are exactly in line with what I experienced  
> > when I migrated.
>
> > autocrlf is what you would use for a mixed development environment,  
> > where Windows clients would want to shift to CRLF in working copy  
> > and back to LF on commit.
>
> > Because Spark code is natively CRLF I turned off the setting to have  
> > the true file format in source control and avoid the whole round-

> > tripping mess.

> >> On Thu, Mar 11, 2010 at 17:27, Olle de Zwart <o...@endforward.nl>  

[Christopher Pelatari]

There is TortoiseGit as well.

--
-Christopher Pelatari | http://bluefenix.net

[Bret Ferrier (runxc1)]

I have been using TortoiseGit with mixed success.

[Christopher Pelatari]

I prefer the command line when using git. gitk for history viewing.

--
-Christopher Pelatari | http://bluefenix.net

On Tue, Mar 16, 2010 at 2:25 PM, Bret Ferrier (runxc1) <run...@gmail.com> wrote:
> I have been using TortoiseGit with mixed success.
>

[Daniel Tabuenca]

I find keeping git gui open all the time encourages frequent and more
focused commits. I also like using git extensions for visual studio:

http://github.com/spdr870/

Mostly just for the ability to bind a hot key to view a complete
history of the current file or undo any changes since the last commit.
It also has most features that git gui/gitk do but I feel the former
tools do a better job.

[tylerl]

I think git is the better DVCS, though mercurial isn't bad. Git has
better support for rebasing, which is a critical thing to have if
you're maintaining a forked release or doing extended work on a
branch. Github does a much better job tracking and visualizing forks
than codeplex; but then they've been at it much longer. The
comparative advantage of github over codeplex in this regard is pretty
dramatic. Spark has 42 forks on github, 17 of them public, and with
relative ease you can see how each compares to the others and what
they provide. Codeplex's support for forks is currently hopelessly
opaque: It's up to you to clone each forks on your own computer and
compare the files yourself. Thanks, but no.

Windows tools for both git and mercurial leave something to be
desired. Both have a "tortoise-" variant, and neither is nearly as
good as subversion's, both have visual studio integration (git's goes
up to vs2010), but again, nothing worth breaking down the door for.

As for where to put things; why is the issue tracker on codeproject,
the forum on google, and the code on github? I think this is the
biggest barrier to contribution for this project: newcomers can't tell
where to go to contribute, and just end up leaving. Github has its own
bug tracker, codeplex has it's own forum. You can already consolidate
and get rid of at least 1 of the 3 services without changing the
workflow.

On Mar 16, 2:54 pm, Daniel Tabuenca <dtabu...@gmail.com> wrote:
> I find keeping git gui open all the time encourages frequent and more
> focused commits. I also like using git extensions for visual studio:
>
> http://github.com/spdr870/
>
> Mostly just for the ability to bind a hot key to view a complete
> history of the current file or undo any changes since the last commit.
> It also has most features that git gui/gitk do but I feel the former
> tools do a better job.
>
> On Tue, Mar 16, 2010 at 12:51, Christopher Pelatari
>

> <christop...@bluefenix.net> wrote:
> > I prefer the command line when using git. gitk for history viewing.
> > --
> > -Christopher Pelatari |http://bluefenix.net
>
> > On Tue, Mar 16, 2010 at 2:25 PM, Bret Ferrier (runxc1) <run...@gmail.com> wrote:
> >> I have been using TortoiseGit with mixed success.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "Spark View Engine Dev" group.
> >> To post to this group, send email to spar...@googlegroups.com.
> >> To unsubscribe from this group, send email to spark-dev+...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/spark-dev?hl=en.

[Louis DeJardin]

Yeah, I think I agree with the DVCS assessment. I also really like the ability to pull and compare forks locally which I haven't seen in mercurial. It loooks like a pull from any repos automatically becomes part of the local line though that could be my own ignorance. It's fantastic codeplex is investing in that direction but it will be a while before it's on par.

For the forums I haven't seen a more seamless integration of forums, mailing list, and archive than the google groups. I often don't even notice whether I'm replying to an email thread or adding a response to the group web interface. Until codeplex or github nails that problem space I don't think that resource could move.

So I'm kind of torn... Issue tracking could move, but downloads and having a codeplex project is really nice... Github issues look a little thin, too... Spark does have too many homes, but to some extent that's an effect of looking for the best free option available for each artifact.