You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Martin Klähn <gr...@gmail.com> on 2017/09/17 10:51:08 UTC
Git line endings
Hi guys,
while checking out the Issue 59 ([1]) and its Pull Request [2] something
came to my attention. In that pull request are two files that have
literally been completely rewritten due to a change in the lineendings thus
making it very difficult to discern what has changed in them.
In the wiki at netbeans.org there's a page [3] essentially explaining how
to work with the sources ( under version control. The DVCS there is
Mercurial and the page contained a quick intro into how to work with
Mercurial and how to configure it. The configurations also contained auto
correction of lineendings and settings of usernames, emails, plugins, etc..
Now I'm not saying we should create such a page as well, even though it may
prove prudent to do so. What was good about that page is that it ensured
that the effect described above did not happen very often.
Hopefully there's a precedent within other Apache projects on how to handle
this.
However if there's not a litte investingation shows to two options we can
take to ensure "proper" lineending. [4] describes both of those options.
The first is that [git config core.autocrlf command is used to change how
Git handles line endings. It takes a single argument]. Optionally with the
--global parameter. This is a setting every commiter has to configure
themselves.
The other is that [you can configure the way Git manages line endings on a
per-repository basis by configuring a special *.gitattributes* file. This
file is committed into the repository and overrides an individual's
core.autocrlf setting, ensuring consistent behavior for all users,
regardless of their Git settings. The advantage of a *.gitattributes* file
is that your line configurations are associated with your repository. You
don't need to worry about whether or not collaborators have the same line
ending settings that you do.]
One word of caution for the .gitattributes solution is that certain tools
such as Egit or JGit will ignore .gitattribute files (see [5])
Ultimately there are two questions.
1. Do we care if files get reformatted because they were edited on
different OSs due to differint lineendings?
2. If so, what are we going to do to prevent that from happening?
Regards
Martin
[1] https://issues.apache.org/jira/browse/NETBEANS-59
[2] https://github.com/apache/incubator-netbeans/pull/1
[3] http://wiki.netbeans.org/HgHowTos#Configuring_Mercurial
[4] https://help.github.com/articles/dealing-with-line-endings/#platform-all
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
Re: Git line endings
Posted by Tushar Joshi <tu...@apache.org>.
We will also need a .gitignore file at the root directory to ignore all
build folders. I have to clean all of them just to apply the new branch.
with regards
Tushar
Re: Git line endings
Posted by Jan Lahoda <la...@gmail.com>.
Christian,
I concur with Martin and Emilian: the commits contain gratuitous changes,
due to change in line endings. I propose that we:
-strive for patches without unnecessary changes
-use LF as the line endings in the repository, as it always was for
NetBeans (VCS should (was definitely true for hg and cvs) be able to change
them to platform-specific line endings if needed for the given platform)
(please see e.g.: the changes to
core.multiview/src/org/netbeans/core/multiview/SplitAction.java in the pull
request - the patch is printed as whole file removed and added - it is
extremely difficult to review such a patch.)
I also wonder what editor was used to do the changes - NetBeans editor is
(AFAIK) supposed to keep existing line endings when writing a file. So if
NB was used to do the editing, we may have a bug to investigate.
I didn't look too deeply at the changes yet, but I probably wouldn't split
out the actions into separate files. But that's a matter of style, of
course.
Two more comments:
-I'd suggest to wait with changes until the bulk of the changes in license
headers is done
-we may want to focus on producing a release and be cautious with new
features and complicated/huge bugfixes.
Jan
On Sun, Sep 17, 2017 at 2:54 PM, Emilian Bold <em...@gmail.com>
wrote:
> Chris, please re-do your commit.
>
> Even the copyright header looks like removed and re-added because you
> probably used Windows line endings.
>
> --emi
>
>
> On Sun, Sep 17, 2017 at 3:16 PM, Christian Lenz <ch...@gmx.net>
> wrote:
> > Hey Martin,
> >
> > thx for having a look in my PR and the ticket 😊 Of Course the files are
> rewritten, because as you can see, I use now a base class and extends it
> for the 2 split Actions. So I think there is no need to be worry about. Of
> Course the files are not so completely new, but most of the code is
> rewritten. I was preventing to reformat the SplitAction file, because than
> you can’t see the changes.
> >
> > In General I understand your point what you mean. Only to let you know
> that 😊
> >
> > Regards
> >
> > Chris
> >
> > Von: Martin Klähn
> > Gesendet: Sonntag, 17. September 2017 12:51
> > An: dev@netbeans.incubator.apache.org
> > Betreff: Git line endings
> >
> > Hi guys,
> >
> > while checking out the Issue 59 ([1]) and its Pull Request [2] something
> > came to my attention. In that pull request are two files that have
> > literally been completely rewritten due to a change in the lineendings
> thus
> > making it very difficult to discern what has changed in them.
> >
> > In the wiki at netbeans.org there's a page [3] essentially explaining
> how
> > to work with the sources ( under version control. The DVCS there is
> > Mercurial and the page contained a quick intro into how to work with
> > Mercurial and how to configure it. The configurations also contained auto
> > correction of lineendings and settings of usernames, emails, plugins,
> etc..
> >
> > Now I'm not saying we should create such a page as well, even though it
> may
> > prove prudent to do so. What was good about that page is that it ensured
> > that the effect described above did not happen very often.
> >
> > Hopefully there's a precedent within other Apache projects on how to
> handle
> > this.
> > However if there's not a litte investingation shows to two options we can
> > take to ensure "proper" lineending. [4] describes both of those options.
> >
> > The first is that [git config core.autocrlf command is used to change how
> > Git handles line endings. It takes a single argument]. Optionally with
> the
> > --global parameter. This is a setting every commiter has to configure
> > themselves.
> >
> > The other is that [you can configure the way Git manages line endings on
> a
> > per-repository basis by configuring a special *.gitattributes* file. This
> > file is committed into the repository and overrides an individual's
> > core.autocrlf setting, ensuring consistent behavior for all users,
> > regardless of their Git settings. The advantage of a *.gitattributes*
> file
> > is that your line configurations are associated with your repository. You
> > don't need to worry about whether or not collaborators have the same line
> > ending settings that you do.]
> >
> > One word of caution for the .gitattributes solution is that certain tools
> > such as Egit or JGit will ignore .gitattribute files (see [5])
> >
> >
> > Ultimately there are two questions.
> >
> > 1. Do we care if files get reformatted because they were edited on
> > different OSs due to differint lineendings?
> >
> > 2. If so, what are we going to do to prevent that from happening?
> >
> > Regards
> > Martin
> >
> > [1] https://issues.apache.org/jira/browse/NETBEANS-59
> > [2] https://github.com/apache/incubator-netbeans/pull/1
> > [3] http://wiki.netbeans.org/HgHowTos#Configuring_Mercurial
> > [4] https://help.github.com/articles/dealing-with-line-
> endings/#platform-all
> > [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
> >
>
Re: Git line endings
Posted by Emilian Bold <em...@gmail.com>.
Chris, please re-do your commit.
Even the copyright header looks like removed and re-added because you
probably used Windows line endings.
--emi
On Sun, Sep 17, 2017 at 3:16 PM, Christian Lenz <ch...@gmx.net> wrote:
> Hey Martin,
>
> thx for having a look in my PR and the ticket 😊 Of Course the files are rewritten, because as you can see, I use now a base class and extends it for the 2 split Actions. So I think there is no need to be worry about. Of Course the files are not so completely new, but most of the code is rewritten. I was preventing to reformat the SplitAction file, because than you can’t see the changes.
>
> In General I understand your point what you mean. Only to let you know that 😊
>
> Regards
>
> Chris
>
> Von: Martin Klähn
> Gesendet: Sonntag, 17. September 2017 12:51
> An: dev@netbeans.incubator.apache.org
> Betreff: Git line endings
>
> Hi guys,
>
> while checking out the Issue 59 ([1]) and its Pull Request [2] something
> came to my attention. In that pull request are two files that have
> literally been completely rewritten due to a change in the lineendings thus
> making it very difficult to discern what has changed in them.
>
> In the wiki at netbeans.org there's a page [3] essentially explaining how
> to work with the sources ( under version control. The DVCS there is
> Mercurial and the page contained a quick intro into how to work with
> Mercurial and how to configure it. The configurations also contained auto
> correction of lineendings and settings of usernames, emails, plugins, etc..
>
> Now I'm not saying we should create such a page as well, even though it may
> prove prudent to do so. What was good about that page is that it ensured
> that the effect described above did not happen very often.
>
> Hopefully there's a precedent within other Apache projects on how to handle
> this.
> However if there's not a litte investingation shows to two options we can
> take to ensure "proper" lineending. [4] describes both of those options.
>
> The first is that [git config core.autocrlf command is used to change how
> Git handles line endings. It takes a single argument]. Optionally with the
> --global parameter. This is a setting every commiter has to configure
> themselves.
>
> The other is that [you can configure the way Git manages line endings on a
> per-repository basis by configuring a special *.gitattributes* file. This
> file is committed into the repository and overrides an individual's
> core.autocrlf setting, ensuring consistent behavior for all users,
> regardless of their Git settings. The advantage of a *.gitattributes* file
> is that your line configurations are associated with your repository. You
> don't need to worry about whether or not collaborators have the same line
> ending settings that you do.]
>
> One word of caution for the .gitattributes solution is that certain tools
> such as Egit or JGit will ignore .gitattribute files (see [5])
>
>
> Ultimately there are two questions.
>
> 1. Do we care if files get reformatted because they were edited on
> different OSs due to differint lineendings?
>
> 2. If so, what are we going to do to prevent that from happening?
>
> Regards
> Martin
>
> [1] https://issues.apache.org/jira/browse/NETBEANS-59
> [2] https://github.com/apache/incubator-netbeans/pull/1
> [3] http://wiki.netbeans.org/HgHowTos#Configuring_Mercurial
> [4] https://help.github.com/articles/dealing-with-line-endings/#platform-all
> [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
>
AW: Git line endings
Posted by Christian Lenz <ch...@gmx.net>.
Hey Martin,
thx for having a look in my PR and the ticket 😊 Of Course the files are rewritten, because as you can see, I use now a base class and extends it for the 2 split Actions. So I think there is no need to be worry about. Of Course the files are not so completely new, but most of the code is rewritten. I was preventing to reformat the SplitAction file, because than you can’t see the changes.
In General I understand your point what you mean. Only to let you know that 😊
Regards
Chris
Von: Martin Klähn
Gesendet: Sonntag, 17. September 2017 12:51
An: dev@netbeans.incubator.apache.org
Betreff: Git line endings
Hi guys,
while checking out the Issue 59 ([1]) and its Pull Request [2] something
came to my attention. In that pull request are two files that have
literally been completely rewritten due to a change in the lineendings thus
making it very difficult to discern what has changed in them.
In the wiki at netbeans.org there's a page [3] essentially explaining how
to work with the sources ( under version control. The DVCS there is
Mercurial and the page contained a quick intro into how to work with
Mercurial and how to configure it. The configurations also contained auto
correction of lineendings and settings of usernames, emails, plugins, etc..
Now I'm not saying we should create such a page as well, even though it may
prove prudent to do so. What was good about that page is that it ensured
that the effect described above did not happen very often.
Hopefully there's a precedent within other Apache projects on how to handle
this.
However if there's not a litte investingation shows to two options we can
take to ensure "proper" lineending. [4] describes both of those options.
The first is that [git config core.autocrlf command is used to change how
Git handles line endings. It takes a single argument]. Optionally with the
--global parameter. This is a setting every commiter has to configure
themselves.
The other is that [you can configure the way Git manages line endings on a
per-repository basis by configuring a special *.gitattributes* file. This
file is committed into the repository and overrides an individual's
core.autocrlf setting, ensuring consistent behavior for all users,
regardless of their Git settings. The advantage of a *.gitattributes* file
is that your line configurations are associated with your repository. You
don't need to worry about whether or not collaborators have the same line
ending settings that you do.]
One word of caution for the .gitattributes solution is that certain tools
such as Egit or JGit will ignore .gitattribute files (see [5])
Ultimately there are two questions.
1. Do we care if files get reformatted because they were edited on
different OSs due to differint lineendings?
2. If so, what are we going to do to prevent that from happening?
Regards
Martin
[1] https://issues.apache.org/jira/browse/NETBEANS-59
[2] https://github.com/apache/incubator-netbeans/pull/1
[3] http://wiki.netbeans.org/HgHowTos#Configuring_Mercurial
[4] https://help.github.com/articles/dealing-with-line-endings/#platform-all
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372