Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nebula-dev] Dealing with line endings

I have found some more info on this here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=424041

and



On Thu, Dec 12, 2013 at 4:23 PM, <Matthew.Webber@xxxxxxxxxxxxx> wrote:
We certainly check in .settings/*, .project etc. into the repository, and I think this is good practice.

The eclipse preferences mentioned are a good idea, but of course only work for files created through Eclipse. Still, better than nothing.

> -----Original Message-----
> From: nebula-dev-bounces@xxxxxxxxxxx [mailto:nebula-dev-bounces@xxxxxxxxxxx] On Behalf Of Max
> Hohenegger
> Sent: 12 December 2013 14:26
> To: Nebula Dev
> Subject: Re: [nebula-dev] Dealing with line endings
>
> In the Eclipse preferences you could set the "New text file line delimiter"
> option to Unix. If you set this option for each Nebula project and manage the
> preference file through git, it should be the default for everybody
> working on Nebula (with Eclipse).
>
> http://stackoverflow.com/questions/1886185/eclipse-and-windows-newlines
> Would that be sufficient?
>
> Cheers
> Max
>
> On Wed, 11 Dec 2013, Dirk Fauth wrote:
> > Not sure, what do you think? I wasn't aware that .gitattributes is not
> > working in EGit, too.
> >
> >
> > On Wed, Dec 11, 2013 at 2:44 PM, Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
> >
> > > Oops. Thanks Matthew. Maybe file a bug anyway Dirk?
> > >
> > >
> > > On Wed, Dec 11, 2013 at 2:31 PM, <Matthew.Webber@xxxxxxxxxxxxx> wrote:
> > >
> > >>  Unfortunately EGit/JGit does not use .gitattributes, which can lead to
> > >> problems if you used a mixed “command line git”/EGit workflow - do a
> > >> bugzilla search for gitattributes.
> > >>
> > >>
> > >>
> > >> I suspect that  use of .gitattributes for Nebula is not suitable.
> > >>
> > >>
> > >>
> > >> Matthew
> > >>
> > >>
> > >>
> > >> *From:* nebula-dev-bounces@xxxxxxxxxxx [mailto:
> > >> nebula-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Dirk Fauth
> > >> *Sent:* 11 December 2013 13:22
> > >> *To:* Nebula Dev
> > >> *Subject:* Re: [nebula-dev] Dealing with line endings
> > >>
> > >>
> > >>
> > >> Here are some additional resources:
> > >>
> > >> http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
> > >> http://schacon.github.io/git/gitattributes.html (important is the
> > >> section on normalization, as the one in the first link didn't work 100% in
> > >> NatTable)
> > >>
> > >> I also attach a sample .gitattributes to this mail. This is the one we
> > >> are using in NatTable.
> > >>
> > >> Although I'm a Nebula committer, I don't want to perform actions that
> > >> potentially will touch a lot of source files in the whole Nebula project.
> > >> Maybe Wim will test this first locally?
> > >>
> > >> Greez,
> > >> Dirk
> > >>
> > >>
> > >>
> > >> On Tue, Dec 10, 2013 at 5:11 PM, Wim Jongman <wim.jongman@xxxxxxxxx>
> > >> wrote:
> > >>
> > >> +1
> > >>
> > >>
> > >>
> > >> On Tue, Dec 10, 2013 at 2:08 PM, Dirk Fauth <dirk.fauth@xxxxxxxxx> wrote:
> > >>
> > >>      Hi,
> > >>
> > >> I just came across the line ending issues when working with Git where the
> > >> OS of the committers is not unique.
> > >>
> > >> In [1] is explained that you can handle this by local Git configuration
> > >> (core.autocrlf) and/or via .gitattributes directly in the repository.
> > >> Adding the .gitattributes should handle things correctly even if the local
> > >> Git configuration property is missing. At least I understand it that way.
> > >>
> > >> Wouldn't it make sense then to add such a .gitattributes to Nebula too?
> > >> Rejecting contributions because of wrong line endings when it can be
> > >> handled automatically feels wrong.
> > >>
> > >> What do you think?
> > >>
> > >> Greez,
> > >>
> > >> Dirk
> > >>
> > >>
> > >> [1] https://help.github.com/articles/dealing-with-line-endings
> > >>
_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev


Back to the top