From: Martin B. <dr....@t-...> - 2013-10-04 11:13:33
Attachments:
signature.asc
|
Hi, i am running into repeated whitespace problems again and again. Please have a look at the following article and lets discuss if that is a valid way to avoid them in the future :) https://help.github.com/articles/dealing-with-line-endings Kind Regards, Martin |
From: brett l. <bre...@gm...> - 2013-10-04 13:33:10
|
+1 from me. IMO, it should be: text eol=lf ---Brett. On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm <dr....@t-...>wrote: > Hi, > > i am running into repeated whitespace problems again and again. > > Please have a look at the following article and lets discuss if that is > a valid way to avoid them in the future :) > > https://help.github.com/articles/dealing-with-line-endings > > Kind Regards, > Martin > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Martin B. <dr....@t-...> - 2013-10-05 19:25:00
Attachments:
signature.asc
|
Hi Brett, i rather thought it should be * text=auto ? Rgrds, Martin Am 04.10.2013 15:32, schrieb brett lentz: > +1 from me. > > IMO, it should be: > > > text eol=lf > > > > ---Brett. > > > On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm > <dr....@t-... <mailto:dr....@t-...>> wrote: > > Hi, > > i am running into repeated whitespace problems again and again. > > Please have a look at the following article and lets discuss if > that is > a valid way to avoid them in the future :) > > https://help.github.com/articles/dealing-with-line-endings > > Kind Regards, > Martin > > |
From: brett l. <bre...@gm...> - 2013-10-06 15:16:39
|
The issue is that we want line endings to be consistent in the repository, regardless of platform. Text=auto just sets all of the line endings to whatever your platform is using. See the documentation on the core.autocrlf and core.safecrlf config options: https://www.kernel.org/pub/software/scm/git/docs/git-config.html Basically, we just need to agree whether LF or CRLF will be the "standard" for the repository, and ensure the repository is configured to auto-convert in the correct direction when committing and pushing changes. ---Brett. ---Brett. On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm <dr....@t-...>wrote: > Hi Brett, > > i rather thought it should be > * text=auto ? > > Rgrds, > Martin > > Am 04.10.2013 15:32, schrieb brett lentz: > > +1 from me. > > IMO, it should be: > text eol=lf > > > ---Brett. > > > On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm <dr....@t-...>wrote: > >> Hi, >> >> i am running into repeated whitespace problems again and again. >> >> Please have a look at the following article and lets discuss if that is >> a valid way to avoid them in the future :) >> >> https://help.github.com/articles/dealing-with-line-endings >> >> Kind Regards, >> Martin >> >> >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Stefan F. <ste...@we...> - 2013-10-14 06:03:55
|
Sorry for replying so late, I took me some time to understand how git is working exactly. And as it is usual for difficult problems, there are legacy issues involved, in this case it is an legacy issue of git to solve a legacy issue of text files ;-) Best explanation I found was: http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ Best stackoverflow entry (which points to the article above) http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git Best template for of .gitattributes for a java repo: https://github.com/Danimoth/gitattributes/blob/master/Java.gitattributes And the man page for gitattributes is very instructive as well. So for me it seems best way to solve that for future problems to add a .gitattributes file similar to the java template above to the repo and then commit the normalization to the repo. This has to be done once by one user of the repo. I would to do this change, as soon as I have the "go ahead" command from at least Erik and Brett. Stefan PS: A) Interesting detail is the the best answer and the best article still differ in best practice for including a default line in .gitattributes: # Auto detect text files and perform LF normalization * text=auto Article discourages such a strategy (see bottom paragraph), however Stackoverflow answer example includes it: B) It seems that git normalizes to LF internally always. What you get on checkout from the repo (or more precisely from your local copy of the git object database) depends first on the setting of "eol" in .gitattributes (if specified) and then on the local core.autocrlf definition of the user. Thus in our scenario we would have LF internally, but still converting to CRLF for the windows users. On 10/06/2013 05:16 PM, brett lentz wrote: > The issue is that we want line endings to be consistent in the > repository, regardless of platform. > > Text=auto just sets all of the line endings to whatever your platform is > using. > > See the documentation on the core.autocrlf and core.safecrlf config > options: https://www.kernel.org/pub/software/scm/git/docs/git-config.html > > Basically, we just need to agree whether LF or CRLF will be the > "standard" for the repository, and ensure the repository is configured > to auto-convert in the correct direction when committing and pushing > changes. > > ---Brett. > > > ---Brett. > > > On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm > <dr....@t-... <mailto:dr....@t-...>> wrote: > > Hi Brett, > > i rather thought it should be > * text=auto ? > > Rgrds, > Martin > > Am 04.10.2013 15:32, schrieb brett lentz: >> +1 from me. >> >> IMO, it should be: >> >> >> text eol=lf >> >> >> >> ---Brett. >> >> >> On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm >> <dr....@t-... <mailto:dr....@t-...>> >> wrote: >> >> Hi, >> >> i am running into repeated whitespace problems again and again. >> >> Please have a look at the following article and lets discuss >> if that is >> a valid way to avoid them in the future :) >> >> https://help.github.com/articles/dealing-with-line-endings >> >> Kind Regards, >> Martin >> >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: brett l. <bre...@gm...> - 2013-10-14 12:43:54
|
+1. A .gitattributes file sounds like it solves the issue. ---Brett ---Brett. On Mon, Oct 14, 2013 at 2:03 AM, Stefan Frey <ste...@we...> wrote: > Sorry for replying so late, I took me some time to understand how git is > working exactly. And as it is usual for difficult problems, there are > legacy issues involved, in this case it is an legacy issue of git to > solve a legacy issue of text files ;-) > > Best explanation I found was: > http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ > > Best stackoverflow entry (which points to the article above) > > http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git > > Best template for of .gitattributes for a java repo: > https://github.com/Danimoth/gitattributes/blob/master/Java.gitattributes > > And the man page for gitattributes is very instructive as well. > > So for me it seems best way to solve that for future problems to add a > .gitattributes file similar to the java template above to the repo and > then commit the normalization to the repo. This has to be done once by > one user of the repo. > > I would to do this change, as soon as I have the "go ahead" command from > at least Erik and Brett. > > Stefan > > PS: > A) Interesting detail is the the best answer and the best article still > differ in best practice for including a default line in .gitattributes: > > # Auto detect text files and perform LF normalization > * text=auto > > Article discourages such a strategy (see bottom paragraph), however > Stackoverflow answer example includes it: > > B) It seems that git normalizes to LF internally always. What you get on > checkout from the repo (or more precisely from your local copy of > the git object database) depends first on the setting of "eol" in > .gitattributes (if specified) and then on the local core.autocrlf > definition of the user. > > Thus in our scenario we would have LF internally, but still converting > to CRLF for the windows users. > > > > On 10/06/2013 05:16 PM, brett lentz wrote: > > The issue is that we want line endings to be consistent in the > > repository, regardless of platform. > > > > Text=auto just sets all of the line endings to whatever your platform is > > using. > > > > See the documentation on the core.autocrlf and core.safecrlf config > > options: > https://www.kernel.org/pub/software/scm/git/docs/git-config.html > > > > Basically, we just need to agree whether LF or CRLF will be the > > "standard" for the repository, and ensure the repository is configured > > to auto-convert in the correct direction when committing and pushing > > changes. > > > > ---Brett. > > > > > > ---Brett. > > > > > > On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm > > <dr....@t-... <mailto:dr....@t-...>> > wrote: > > > > Hi Brett, > > > > i rather thought it should be > > * text=auto ? > > > > Rgrds, > > Martin > > > > Am 04.10.2013 15:32, schrieb brett lentz: > >> +1 from me. > >> > >> IMO, it should be: > >> > >> > >> text eol=lf > >> > >> > >> > >> ---Brett. > >> > >> > >> On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm > >> <dr....@t-... <mailto:dr....@t-...>> > >> wrote: > >> > >> Hi, > >> > >> i am running into repeated whitespace problems again and again. > >> > >> Please have a look at the following article and lets discuss > >> if that is > >> a valid way to avoid them in the future :) > >> > >> https://help.github.com/articles/dealing-with-line-endings > >> > >> Kind Regards, > >> Martin > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > > most from > > the latest Intel processors and coprocessors. See abstracts and > > register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Stefan F. <ste...@we...> - 2014-03-06 10:10:07
|
I have added the .gitattributes to rails_2_develop and normalized the repo. Please check if everything still works fine with your settings after you pull rails_2_develop. Stefan On 10/14/2013 08:03 AM, Stefan Frey wrote: > Sorry for replying so late, I took me some time to understand how git > is working exactly. And as it is usual for difficult problems, there > are legacy issues involved, in this case it is an legacy issue of git > to solve a legacy issue of text files ;-) > > Best explanation I found was: > http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ > > Best stackoverflow entry (which points to the article above) > http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git > > > Best template for of .gitattributes for a java repo: > https://github.com/Danimoth/gitattributes/blob/master/Java.gitattributes > > And the man page for gitattributes is very instructive as well. > > So for me it seems best way to solve that for future problems to add a > .gitattributes file similar to the java template above to the repo and > then commit the normalization to the repo. This has to be done once by > one user of the repo. > > I would to do this change, as soon as I have the "go ahead" command > from at least Erik and Brett. > > Stefan > > PS: > A) Interesting detail is the the best answer and the best article > still differ in best practice for including a default line in > .gitattributes: > > # Auto detect text files and perform LF normalization > * text=auto > > Article discourages such a strategy (see bottom paragraph), however > Stackoverflow answer example includes it: > > B) It seems that git normalizes to LF internally always. What you get > on checkout from the repo (or more precisely from your local copy of > the git object database) depends first on the setting of "eol" in > .gitattributes (if specified) and then on the local core.autocrlf > definition of the user. > > Thus in our scenario we would have LF internally, but still converting > to CRLF for the windows users. > > > > On 10/06/2013 05:16 PM, brett lentz wrote: >> The issue is that we want line endings to be consistent in the >> repository, regardless of platform. >> >> Text=auto just sets all of the line endings to whatever your platform is >> using. >> >> See the documentation on the core.autocrlf and core.safecrlf config >> options: >> https://www.kernel.org/pub/software/scm/git/docs/git-config.html >> >> Basically, we just need to agree whether LF or CRLF will be the >> "standard" for the repository, and ensure the repository is configured >> to auto-convert in the correct direction when committing and pushing >> changes. >> >> ---Brett. >> >> >> ---Brett. >> >> >> On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm >> <dr....@t-... <mailto:dr....@t-...>> >> wrote: >> >> Hi Brett, >> >> i rather thought it should be >> * text=auto ? >> >> Rgrds, >> Martin >> >> Am 04.10.2013 15:32, schrieb brett lentz: >>> +1 from me. >>> >>> IMO, it should be: >>> >>> >>> text eol=lf >>> >>> >>> >>> ---Brett. >>> >>> >>> On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm >>> <dr....@t-... <mailto:dr....@t-...>> >>> wrote: >>> >>> Hi, >>> >>> i am running into repeated whitespace problems again and again. >>> >>> Please have a look at the following article and lets discuss >>> if that is >>> a valid way to avoid them in the future :) >>> >>> https://help.github.com/articles/dealing-with-line-endings >>> >>> Kind Regards, >>> Martin >>> >>> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> <mailto:Rai...@li...> >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> >> >> >> >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > |