Re: git line endings trouble since recent trunk
The problem seems to happen again on the latest trunk On Mon, Jul 1, 2013 at 11:44 AM, Colin McCabe cmcc...@alumni.cmu.eduwrote: On Mon, Jul 1, 2013 at 11:09 AM, Raja Aluri r...@cmbasics.com wrote: They are not that many that I can think of unless you are using notepad for editing, but some of the windows related files might require CRLF. This can be handled in .gitattributes I think it's a very good idea to add this check to test-patch script and reject the patch based on the CRLF check. -Raja I don't see why you would need a hook. Just set svn:eol-style=crlf on the file that need CRLF. On Mon, Jul 1, 2013 at 11:00 AM, Alejandro Abdelnur t...@cloudera.com wrote: why not just add a precommit hook in svn to reject commits with CRLF? On Mon, Jul 1, 2013 at 10:51 AM, Raja Aluri r...@cmbasics.com wrote: I added a couple of links that discusses 'line endings' when I added .gitattributes in this JIRA. HADOOP-8912https://issues.apache.org/jira/browse/HADOOP-8912 I am just reproducing them here. 1. http://git-scm.com/docs/gitattributes#_checking_out_and_checking_in 2. http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git Regardless of what we do or don't do in git, we should have the line endings correct in subversion. cheers. Colin -- Raja On Mon, Jul 1, 2013 at 10:42 AM, Colin McCabe cmcc...@alumni.cmu.edu wrote: On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu l...@vicaya.com wrote: The problem is due to relnotes.py generating the html containing some CRLF (from JIRA) and the release manager not using git-svn, which caused the html with mixed eol getting checked in. The problem would then manifest for git users due to text=auto in .gitattributes (see HADOOP-8912) that auto converts CRLF to LF, hence the persistent modified status of the releasenotes.html for a fresh checkout. Adding svn:eol-style=native would only fix half the problem. We need to fix relnotes.py to avoid generating html with mixed eols (by normalizing everything to LF or native). While I agree that it would be nice to fix relnotes.py, it seems to me that setting svn:eol-style=native should fix the problem completely. Files with this attribute set are stored internally by subversion with all newlines as LF, and converted to CRLF as needed. After all, eol-style=native would not be very useful if it only applied on checkout. Windows users would be constantly checking in CRLF in that case. I'm not an svn expert, though, and I haven't tested the above. Colin On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows
Re: git line endings trouble since recent trunk
Yes on hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html. This does not appear to affect devs in my group with older git 1.7.1, but it does affect git 1.8.1.2 and fiddling with the options autocrlf and safecrlf could not produce a combination that prevents it from changing the line endings to LF on checkout. On 8/1/13 3:31 PM, Zhijie Shen zs...@hortonworks.com wrote: The problem seems to happen again on the latest trunk On Mon, Jul 1, 2013 at 11:44 AM, Colin McCabe cmcc...@alumni.cmu.eduwrote: On Mon, Jul 1, 2013 at 11:09 AM, Raja Aluri r...@cmbasics.com wrote: They are not that many that I can think of unless you are using notepad for editing, but some of the windows related files might require CRLF. This can be handled in .gitattributes I think it's a very good idea to add this check to test-patch script and reject the patch based on the CRLF check. -Raja I don't see why you would need a hook. Just set svn:eol-style=crlf on the file that need CRLF. On Mon, Jul 1, 2013 at 11:00 AM, Alejandro Abdelnur t...@cloudera.com wrote: why not just add a precommit hook in svn to reject commits with CRLF? On Mon, Jul 1, 2013 at 10:51 AM, Raja Aluri r...@cmbasics.com wrote: I added a couple of links that discusses 'line endings' when I added .gitattributes in this JIRA. HADOOP-8912https://issues.apache.org/jira/browse/HADOOP-8912 I am just reproducing them here. 1. http://git-scm.com/docs/gitattributes#_checking_out_and_checking_in 2. http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-st rategy-with-git Regardless of what we do or don't do in git, we should have the line endings correct in subversion. cheers. Colin -- Raja On Mon, Jul 1, 2013 at 10:42 AM, Colin McCabe cmcc...@alumni.cmu.edu wrote: On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu l...@vicaya.com wrote: The problem is due to relnotes.py generating the html containing some CRLF (from JIRA) and the release manager not using git-svn, which caused the html with mixed eol getting checked in. The problem would then manifest for git users due to text=auto in .gitattributes (see HADOOP-8912) that auto converts CRLF to LF, hence the persistent modified status of the releasenotes.html for a fresh checkout. Adding svn:eol-style=native would only fix half the problem. We need to fix relnotes.py to avoid generating html with mixed eols (by normalizing everything to LF or native). While I agree that it would be nice to fix relnotes.py, it seems to me that setting svn:eol-style=native should fix the problem completely. Files with this attribute set are stored internally by subversion with all newlines as LF, and converted to CRLF as needed. After all, eol-style=native would not be very useful if it only applied on checkout. Windows users would be constantly checking in CRLF in that case. I'm not an svn expert, though, and I haven't tested the above. Colin On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually
Re: git line endings trouble since recent trunk
On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu l...@vicaya.com wrote: The problem is due to relnotes.py generating the html containing some CRLF (from JIRA) and the release manager not using git-svn, which caused the html with mixed eol getting checked in. The problem would then manifest for git users due to text=auto in .gitattributes (see HADOOP-8912) that auto converts CRLF to LF, hence the persistent modified status of the releasenotes.html for a fresh checkout. Adding svn:eol-style=native would only fix half the problem. We need to fix relnotes.py to avoid generating html with mixed eols (by normalizing everything to LF or native). While I agree that it would be nice to fix relnotes.py, it seems to me that setting svn:eol-style=native should fix the problem completely. Files with this attribute set are stored internally by subversion with all newlines as LF, and converted to CRLF as needed. After all, eol-style=native would not be very useful if it only applied on checkout. Windows users would be constantly checking in CRLF in that case. I'm not an svn expert, though, and I haven't tested the above. Colin On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe cmcc...@alumni.cmu.eduwrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
Re: git line endings trouble since recent trunk
I added a couple of links that discusses 'line endings' when I added .gitattributes in this JIRA. HADOOP-8912https://issues.apache.org/jira/browse/HADOOP-8912 I am just reproducing them here. 1. http://git-scm.com/docs/gitattributes#_checking_out_and_checking_in 2. http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git -- Raja On Mon, Jul 1, 2013 at 10:42 AM, Colin McCabe cmcc...@alumni.cmu.eduwrote: On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu l...@vicaya.com wrote: The problem is due to relnotes.py generating the html containing some CRLF (from JIRA) and the release manager not using git-svn, which caused the html with mixed eol getting checked in. The problem would then manifest for git users due to text=auto in .gitattributes (see HADOOP-8912) that auto converts CRLF to LF, hence the persistent modified status of the releasenotes.html for a fresh checkout. Adding svn:eol-style=native would only fix half the problem. We need to fix relnotes.py to avoid generating html with mixed eols (by normalizing everything to LF or native). While I agree that it would be nice to fix relnotes.py, it seems to me that setting svn:eol-style=native should fix the problem completely. Files with this attribute set are stored internally by subversion with all newlines as LF, and converted to CRLF as needed. After all, eol-style=native would not be very useful if it only applied on checkout. Windows users would be constantly checking in CRLF in that case. I'm not an svn expert, though, and I haven't tested the above. Colin On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
Re: git line endings trouble since recent trunk
why not just add a precommit hook in svn to reject commits with CRLF? On Mon, Jul 1, 2013 at 10:51 AM, Raja Aluri r...@cmbasics.com wrote: I added a couple of links that discusses 'line endings' when I added .gitattributes in this JIRA. HADOOP-8912https://issues.apache.org/jira/browse/HADOOP-8912 I am just reproducing them here. 1. http://git-scm.com/docs/gitattributes#_checking_out_and_checking_in 2. http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git -- Raja On Mon, Jul 1, 2013 at 10:42 AM, Colin McCabe cmcc...@alumni.cmu.edu wrote: On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu l...@vicaya.com wrote: The problem is due to relnotes.py generating the html containing some CRLF (from JIRA) and the release manager not using git-svn, which caused the html with mixed eol getting checked in. The problem would then manifest for git users due to text=auto in .gitattributes (see HADOOP-8912) that auto converts CRLF to LF, hence the persistent modified status of the releasenotes.html for a fresh checkout. Adding svn:eol-style=native would only fix half the problem. We need to fix relnotes.py to avoid generating html with mixed eols (by normalizing everything to LF or native). While I agree that it would be nice to fix relnotes.py, it seems to me that setting svn:eol-style=native should fix the problem completely. Files with this attribute set are stored internally by subversion with all newlines as LF, and converted to CRLF as needed. After all, eol-style=native would not be very useful if it only applied on checkout. Windows users would be constantly checking in CRLF in that case. I'm not an svn expert, though, and I haven't tested the above. Colin On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/ -- Alejandro
Re: git line endings trouble since recent trunk
They are not that many that I can think of unless you are using notepad for editing, but some of the windows related files might require CRLF. This can be handled in .gitattributes I think it's a very good idea to add this check to test-patch script and reject the patch based on the CRLF check. -Raja On Mon, Jul 1, 2013 at 11:00 AM, Alejandro Abdelnur t...@cloudera.comwrote: why not just add a precommit hook in svn to reject commits with CRLF? On Mon, Jul 1, 2013 at 10:51 AM, Raja Aluri r...@cmbasics.com wrote: I added a couple of links that discusses 'line endings' when I added .gitattributes in this JIRA. HADOOP-8912https://issues.apache.org/jira/browse/HADOOP-8912 I am just reproducing them here. 1. http://git-scm.com/docs/gitattributes#_checking_out_and_checking_in 2. http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git -- Raja On Mon, Jul 1, 2013 at 10:42 AM, Colin McCabe cmcc...@alumni.cmu.edu wrote: On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu l...@vicaya.com wrote: The problem is due to relnotes.py generating the html containing some CRLF (from JIRA) and the release manager not using git-svn, which caused the html with mixed eol getting checked in. The problem would then manifest for git users due to text=auto in .gitattributes (see HADOOP-8912) that auto converts CRLF to LF, hence the persistent modified status of the releasenotes.html for a fresh checkout. Adding svn:eol-style=native would only fix half the problem. We need to fix relnotes.py to avoid generating html with mixed eols (by normalizing everything to LF or native). While I agree that it would be nice to fix relnotes.py, it seems to me that setting svn:eol-style=native should fix the problem completely. Files with this attribute set are stored internally by subversion with all newlines as LF, and converted to CRLF as needed. After all, eol-style=native would not be very useful if it only applied on checkout. Windows users would be constantly checking in CRLF in that case. I'm not an svn expert, though, and I haven't tested the above. Colin On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen
Re: git line endings trouble since recent trunk
Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.comwrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
Re: git line endings trouble since recent trunk
Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
Re: git line endings trouble since recent trunk
I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.comwrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
Re: git line endings trouble since recent trunk
I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.comwrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
Re: git line endings trouble since recent trunk
http://www.apache.org/dev/version-control.html#https-svn-config Doug On Jun 28, 2013 1:03 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: Clarification: svn:eol-style = native causes the files to contain whatever the native platform used to check out the code uses. I think just setting this property on all the HTML files should resolve this and future problems. patch posted. C. On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote: I think the fix for this is to set svn:eol-style to native on this file. It's set on many other files, just not on this one: cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-project-dist/README.txt native cmccabe@keter:~/hadoopST/trunk svn propget svn:eol-style ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html cmccabe@keter:~/hadoopST/trunk It might also be a good idea to run dos2unix on it. I thought that in general we wanted to have 'LF' everywhere, so perhaps we should add this to the patch.sh script to prevent this from re-occurring. Colin On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza sandy.r...@cloudera.com wrote: I haven't been able to find a solution. Just filed https://issues.apache.org/jira/browse/HADOOP-9675. On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi ojo...@hortonworks.com wrote: Sandy... did you fix this? any jira to track? me too facing same problem.. Thanks, Omkar Joshi *Hortonworks Inc.* http://www.hortonworks.com On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen zs...@hortonworks.com wrote: Have the same problem here, have to edit the patch manually to exclude the changes in releasenotes.html On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza sandy.r...@cloudera.com wrote: Has anybody else been having trouble with line endings since pulling trunk recently? hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html shows up as modified even though I haven't touched it, and I can't check it out or reset to a previous version to make that go away. The only thing I can do to neutralize it is to put it in a dummy commit, but I have to do this every time I switch branches or rebase. This appears to have began after the release notes commit (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a line endings change. -Sandy -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/
