Git Modularization hiccups
* "git clone --recursive http://github.com/boostorg/boost modular-boost" is mostly working fine here (on Win7) but is producing one set of error messages: Cloning into 'libs/assign'... fatal: reference is not a tree: 57ec5d1534810090649b18c88e66a46f48cdcf1c ... Unable to checkout '57ec5d1534810090649b18c88e66a46f48cdcf1c' in submodule path 'libs/assign' The remaining hiccups are in the root directory, comparing trunk to master: * boost.css is missing content from revisions 36243 and 53553. * boost-build.jam has different comments and history. Something is totally whacky. * boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings. * Same problem with bootstrap.sh. IIRC, it is important that the .sh files have the Unix line endings. * c++boost.gif not present in trunk, present in master. * index.html missing in master. * Jamfile.v2 and Jamroot.jam not present in trunk, present in master. * INSTALL missing in master. * LICENSE_1_0.txt has Unix line endings in trunk, Windows line endings in master. * project-config.jam missing in master. * rst.cc missing in master. * README.txt not present in trunk, present in master. HTH, --Beman
on Thu May 23 2013, Beman Dawes
* "git clone --recursive http://github.com/boostorg/boost modular-boost" is mostly working fine here (on Win7) but is producing one set of error messages:
Cloning into 'libs/assign'... fatal: reference is not a tree: 57ec5d1534810090649b18c88e66a46f48cdcf1c ... Unable to checkout '57ec5d1534810090649b18c88e66a46f48cdcf1c' in submodule path 'libs/assign'
Reproduced here. That's very strange; I'll have to try to figure out why that's happening.
The remaining hiccups are in the root directory, comparing trunk to master:
* boost.css is missing content from revisions 36243 and 53553.
* boost-build.jam has different comments and history. Something is totally whacky.
* boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings.
Oh well, the way line endings are handled in Git and SVN are divergent. Check your .gitconfig against the output of git --help config; especially core.eol, core.safecrlf, and core.autocrlf
* Same problem with bootstrap.sh. IIRC, it is important that the .sh files have the Unix line endings.
* c++boost.gif not present in trunk, present in master.
* index.html missing in master.
* Jamfile.v2 and Jamroot.jam not present in trunk, present in master.
* INSTALL missing in master.
* LICENSE_1_0.txt has Unix line endings in trunk, Windows line endings in master.
* project-config.jam missing in master.
* rst.cc missing in master.
* README.txt not present in trunk, present in master.
I'll look into these; thanks. -- Dave Abrahams
On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
on Thu May 23 2013, Beman Dawes
wrote: The remaining hiccups are in the root directory, comparing trunk to master:
* boost.css is missing content from revisions 36243 and 53553.
* boost-build.jam has different comments and history. Something is totally whacky.
* boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings.
Oh well, the way line endings are handled in Git and SVN are divergent. Check your .gitconfig against the output of git --help config; especially core.eol, core.safecrlf, and core.autocrlf
Shouldn't the repositories contain a .gitattributes file indicating the eol flavor to be used for text files where it has significance? Relying on everyone to mutate their client settings just right doesn't exactly scale out well, particularly not to end users.
* Same problem with bootstrap.sh. IIRC, it is important that the .sh files have the Unix line endings.
* c++boost.gif not present in trunk, present in master.
* index.html missing in master.
* Jamfile.v2 and Jamroot.jam not present in trunk, present in master.
* INSTALL missing in master.
* LICENSE_1_0.txt has Unix line endings in trunk, Windows line endings in master.
* project-config.jam missing in master.
* rst.cc missing in master.
* README.txt not present in trunk, present in master.
I'll look into these; thanks.
-- Lars Viklund | zao@acc.umu.se
on Thu May 23 2013, Lars Viklund
On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
on Thu May 23 2013, Beman Dawes
wrote: The remaining hiccups are in the root directory, comparing trunk to master:
* boost.css is missing content from revisions 36243 and 53553.
* boost-build.jam has different comments and history. Something is totally whacky.
* boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings.
Oh well, the way line endings are handled in Git and SVN are divergent. Check your .gitconfig against the output of git --help config; especially core.eol, core.safecrlf, and core.autocrlf
Shouldn't the repositories contain a .gitattributes file indicating the eol flavor to be used for text files where it has significance?
Perhaps! I don't know anything about .gitattributes. Where can I find out more? -- Dave Abrahams
On Thu, May 23, 2013 at 11:00:19PM -0700, Dave Abrahams wrote:
on Thu May 23 2013, Lars Viklund
wrote: On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
on Thu May 23 2013, Beman Dawes
wrote: The remaining hiccups are in the root directory, comparing trunk to master:
* boost.css is missing content from revisions 36243 and 53553.
* boost-build.jam has different comments and history. Something is totally whacky.
* boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings.
Oh well, the way line endings are handled in Git and SVN are divergent. Check your .gitconfig against the output of git --help config; especially core.eol, core.safecrlf, and core.autocrlf
Shouldn't the repositories contain a .gitattributes file indicating the eol flavor to be used for text files where it has significance?
Perhaps! I don't know anything about .gitattributes. Where can I find out more?
A decent introduction can be found in the Github help pages [1] and in this blog post [2]. You would essentially have entries like: *.sh text eol=lf I'm not quite sure how it all fits together with the config flags, but as I understand it, it's one of the major puzzle pieces in getting a behaviour similiar to the one enforced by our Subversion. Some testing would probably be required to see how the final solution turns out on different clients on the platforms. [1] https://help.github.com/articles/dealing-with-line-endings [2] http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ -- Lars Viklund | zao@acc.umu.se
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Lars Viklund Sent: Friday, May 24, 2013 7:18 AM To: boost@lists.boost.org Subject: Re: [boost] Git Modularization hiccups
On Thu, May 23, 2013 at 11:00:19PM -0700, Dave Abrahams wrote:
on Thu May 23 2013, Lars Viklund
wrote: On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
on Thu May 23 2013, Beman Dawes
wrote: The remaining hiccups are in the root directory, comparing trunk to master:
* boost.css is missing content from revisions 36243 and 53553.
* boost-build.jam has different comments and history. Something is totally whacky.
* boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings.
Oh well, the way line endings are handled in Git and SVN are divergent. Check your .gitconfig against the output of git --help config; especially core.eol, core.safecrlf, and core.autocrlf
Shouldn't the repositories contain a .gitattributes file indicating the eol flavor to be used for text files where it has significance?
Perhaps! I don't know anything about .gitattributes. Where can I find out more?
A decent introduction can be found in the Github help pages [1] and in this blog post [2].
You would essentially have entries like: *.sh text eol=lf
I'm not quite sure how it all fits together with the config flags, but as I understand it, it's one of the major puzzle pieces in getting a behaviour similiar to the one enforced by our Subversion.
Some testing would probably be required to see how the final solution turns out on different clients on the platforms.
[1] https://help.github.com/articles/dealing-with-line-endings [2] http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/
This caused quite a bit of grief with the several types of files in documentation, like jpg, svg, png, and others I don't recall immediately. Finding that you can't commit is really unwanted when you are fumbling with a new tool like GIT. These were missing from the SVN setup file suggested as standard. My current list is [auto-props] # Scriptish formats *.bat = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.bsh = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/x-beanshell *.cgi = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.cmd = svn:eol-style=native; svn:keywords=Id; svn:mine-type=text/plain *.js = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/javascript *.php = svn:eol-style=native; svn:keywords=Id Rev Date; svn:mime-type=text/x-php *.pl = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/x-perl; svn:executable *.pm = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/x-perl *.py = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/x-python; svn:executable *.sh = svn:eol-style=LF; svn:keywords=Id; svn:mime-type=text/x-sh; svn:executable configure = svn:eol-style=LF; svn:keywords=Id; svn:mime-type=text/x-sh; svn:executable # Image formats *.bmp = svn:mime-type=image/bmp *.gif = svn:mime-type=image/gif *.ico = svn:mime-type=image/ico *.jpeg = svn:mime-type=image/jpeg *.jpg = svn:mime-type=image/jpeg *.png = svn:mime-type=image/png *.tif = svn:mime-type=image/tiff *.tiff = svn:mime-type=image/tiff *.svg = svn:eol-style=native; svn:mime-type=text/svg+xml # Data formats *.pdf = svn:mime-type=application/pdf *.avi = svn:mime-type=video/avi *.doc = svn:mime-type=application/msword *.dsp = svn:mime-type=text/plain;svn:eol-style=CRLF *.dsw = svn:mime-type=text/plain;svn:eol-style=CRLF *.eps = svn:mime-type=application/postscript *.gz = svn:mime-type=application/gzip *.mov = svn:mime-type=video/quicktime *.mp3 = svn:mime-type=audio/mpeg *.ppt = svn:mime-type=application/vnd.ms-powerpoint *.ps = svn:mime-type=application/postscript *.psd = svn:mime-type=application/photoshop *.rdf = svn:eol-style=native;svn:keywords=Id *.rss = svn:eol-style=native;svn:keywords=Id *.rtf = svn:mime-type=text/rtf *.sln = svn:eol-style=native;svn:mime-type=text/plain *.swf = svn:mime-type=application/x-shockwave-flash *.tgz = svn:mime-type=application/gzip *.vcproj = svn:eol-style=native;svn:mime-type=text/xml *.vsprops = svn:eol-style=native;svn:mime-type=text/xml *.wav = svn:mime-type=audio/wav *.xls = svn:mime-type=application/vnd.ms-excel *.zip = svn:mime-type=application/zip # Text formats .htaccess = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.bbk = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.cmake = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.css = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/css *.dtd = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.htm = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/html *.html = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/html *.idx = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.ini = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.log = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.mak = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.qbk = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.rst = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.sql = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/x-sql *.txt = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.xhtml = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xhtml+xml *.xml = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.mml = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.xsd = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.xsl = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.xslt = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xml *.xul = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/xul *.yml = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain CHANGES = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain COPYING = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain INSTALL = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain Jamfile = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain Jamroot = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain Jamfile.v2 = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain Jamrules = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain Makefile* = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain README = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain TODO = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain # Code formats *.c = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.cpp = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.h = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.hpp = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.ipp = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.tpp = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.jam = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain *.java = svn:eol-style=native; svn:keywords=Id; svn:mime-type=text/plain I hope we will have all of these - and more - including .sh and .bat. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 24/05/13 11:03, Paul A. Bristow wrote:
This caused quite a bit of grief with the several types of files in documentation, like jpg, svg, png, and others I don't recall immediately.
Finding that you can't commit is really unwanted when you are fumbling with a new tool like GIT.
Disabling the Git feature that automatically converts unix line endings to windows line endings allows to avoid all line endings problems, but requires that you edit all files with a text editor that supports unix line endings.
These were missing from the SVN setup file suggested as standard. My current list is
<snip svn props />
I hope we will have all of these - and more - including .sh and .bat.
There is no need for all of these. *.sh and configure are the only two useful ones in that list. *.bat and *.cmd could be useful, but the value in svn props is wrong, it should force to CRLF.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Friday, May 24, 2013 10:56 AM To: boost@lists.boost.org Subject: Re: [boost] Git Modularization hiccups
On 24/05/13 11:03, Paul A. Bristow wrote:
This caused quite a bit of grief with the several types of files in documentation, like jpg, svg, png, and others I don't recall immediately.
Finding that you can't commit is really unwanted when you are fumbling with a new tool like GIT.
Disabling the Git feature that automatically converts unix line endings to windows line endings allows to avoid all line endings problems, but requires that you edit all files with a text editor that supports unix line endings.
Not very helpful if you are a Windows user? I think this must work fully automatically. (The two groups of people who devised two different line-ending systems should all have their head smashed together! ;-)
These were missing from the SVN setup file suggested as standard. My current list is
<snip svn props />
I hope we will have all of these - and more - including .sh and .bat.
There is no need for all of these. *.sh and configure are the only two useful ones in that list. *.bat and *.cmd could be useful, but the value in svn props is wrong, it should force to CRLF.
I'm only hoping that mere users should not have to do more than import the configuration file. There is going to be more than enough to sort out with migrating to GIT without this issue. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 24 May 2013 11:57, Paul A. Bristow wrote:
Disabling the Git feature that automatically converts unix line endings to windows line endings
allows to
avoid all line endings problems, but requires that you edit all files with a text editor that supports unix line endings.
Not very helpful if you are a Windows user?
Really? How many Windows text editors can't handle non-native line endings these days? (Notepad doesn't count as a text editor, and IMHO it's reasonable to expect Boost contributors to use something other than Notepad - if you can write C++ that works with multiple compilers on multiple platforms then you can use a proper editor.)
Jonathan Wakely wrote:
Really? How many Windows text editors can't handle non-native line endings these days? (Notepad doesn't count as a text editor, and IMHO it's reasonable to expect Boost contributors to use something other than Notepad - if you can write C++ that works with multiple compilers on multiple platforms then you can use a proper editor.)
You have to remember to set the line endings for every new file though.
On 24 May 2013 12:26, Peter Dimov wrote:
Jonathan Wakely wrote:
Really? How many Windows text editors can't handle non-native line endings these days? (Notepad doesn't count as a text editor, and IMHO it's reasonable to expect Boost contributors to use something other than Notepad - if you can write C++ that works with multiple compilers on multiple platforms then you can use a proper editor.)
You have to remember to set the line endings for every new file though.
Only if creating a new file that requires unix line endings, or did I misunderstand? I didn't think the suggestion was that all files must have unix line endings, just that because some require them (e.g. shell scripts with a shebang) that line endings should be preserved. So if you're creating a new shell script with a shebang, it should use unix line endings, but then presumably you'll be creating such scripts on a unix-like OS anyway and this isn't a problem.
On 24/05/13 13:31, Jonathan Wakely wrote:
I didn't think the suggestion was that all files must have unix line endings, just that because some require them (e.g. shell scripts with a shebang) that line endings should be preserved. So if you're creating a new shell script with a shebang, it should use unix line endings, but then presumably you'll be creating such scripts on a unix-like OS anyway and this isn't a problem.
All source files should follow the same line endings convention, that much is a given. The convention that people usually choose (and the one that Boost uses as well) is to store all source files in the Git repository with unix line endings. Only special file types that require windows line endings should have them.
Jonathan Wakely wrote:
I didn't think the suggestion was that all files must have unix line endings, just that because some require them (e.g. shell scripts with a shebang) that line endings should be preserved. So if you're creating a new shell script with a shebang, it should use unix line endings, but then presumably you'll be creating such scripts on a unix-like OS anyway and this isn't a problem.
I recall that .cpp/.hpp files with Windows file endings don't work on Unix when, for example, some lines end with a backslash - only the CR is escaped.
Jonathan Wakely wrote:
Really? How many Windows text editors can't handle non-native line endings these days? (Notepad doesn't count as a text editor, and IMHO it's reasonable to expect Boost contributors to use something other than Notepad - if you can write C++ that works with multiple compilers on multiple platforms then you can use a proper editor.)
You have to remember to set the line endings for every new file though. And if you forget, you have one very popular code editor that preserves
On 2013-05-24 13:26, Peter Dimov wrote: line endings on copy&paste, leaving you with files with mixed line endings.
On 24/05/13 13:33, Sebastian Redl wrote:
Jonathan Wakely wrote:
Really? How many Windows text editors can't handle non-native line endings these days? (Notepad doesn't count as a text editor, and IMHO it's reasonable to expect Boost contributors to use something other than Notepad - if you can write C++ that works with multiple compilers on multiple platforms then you can use a proper editor.)
You have to remember to set the line endings for every new file though. And if you forget, you have one very popular code editor that preserves
On 2013-05-24 13:26, Peter Dimov wrote: line endings on copy&paste, leaving you with files with mixed line endings.
But you will see all of this when you review your diff. Unfortunately, many developers don't seem to even review their own sets of changes before committing them.
[Please do not mail me a copy of your followup]
boost@lists.boost.org spake the secret code
Jonathan Wakely wrote:
Really? How many Windows text editors can't handle non-native line endings these days? (Notepad doesn't count as a text editor, and IMHO it's reasonable to expect Boost contributors to use something other than Notepad - if you can write C++ that works with multiple compilers on multiple platforms then you can use a proper editor.)
You have to remember to set the line endings for every new file though.
There have been some vague non-specific comments on this thread like "one very popular code editor". Instead of being vague, I'll be specific. If you're a Visual Studio user, the "stripem" add-on allows you to enforce a particular line ending for file names matching a regular expression. Where I work, we require LF line endings for source files and I have used this add-on to enforce that requirement. It works great and handles new files and existing files alike. *poof* No need to remember to do a manual step anymore. http://www.grebulon.com/software/stripem.php -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com
[Please do not mail me a copy of your followup] boost@lists.boost.org spake the secret code <006101ce585d$9e765100$db62f300$@hetp.u-net.com> thusly:
# Data formats *.dsp = svn:mime-type=text/plain;svn:eol-style=CRLF *.dsw = svn:mime-type=text/plain;svn:eol-style=CRLF [...]
*.vcproj = svn:eol-style=native;svn:mime-type=text/xml *.vsprops = svn:eol-style=native;svn:mime-type=text/xml
These should be eol-style=CRLF as well. VS will just turn them into CRLFs the next time you manipulate them in the IDE anyway, so they should always be CRLF to avoid EOl churn. You also forgot: *.vcxproj = svn:eol-style=CRLF;svn:mime-type=text/xml *.vcxproj.filters = svn:eol-style=CRLF;svn:mime-type=text/xml (Some people don't put the filters under version control; some do.) -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com
on Thu May 23 2013, Beman Dawes
* "git clone --recursive http://github.com/boostorg/boost modular-boost" is mostly working fine here (on Win7) but is producing one set of error messages:
Cloning into 'libs/assign'... fatal: reference is not a tree: 57ec5d1534810090649b18c88e66a46f48cdcf1c ... Unable to checkout '57ec5d1534810090649b18c88e66a46f48cdcf1c' in submodule path 'libs/assign'
The remaining hiccups are in the root directory, comparing trunk to master: * boost.css is missing content from revisions 36243 and 53553. * boost-build.jam has different comments and history. Something is totally whacky. * boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings. * Same problem with bootstrap.sh. IIRC, it is important that the .sh files have the Unix line endings. * c++boost.gif not present in trunk, present in master. * index.html missing in master. * Jamfile.v2 and Jamroot.jam not present in trunk, present in master. * INSTALL missing in master. * LICENSE_1_0.txt has Unix line endings in trunk, Windows line endings in master. * project-config.jam missing in master. * rst.cc missing in master. * README.txt not present in trunk, present in master.
Hi Beman, You should find these issues cleared up now. Line endings may have to wait for http://jenkins.boost.org/job/Boost2Git/2119 to complete, in about 1 hr or so. Please take a look. -- Dave Abrahams
participants (9)
-
Beman Dawes -
Dave Abrahams -
Jonathan Wakely -
Lars Viklund -
legalize+jeeves＠mail.xmission.com -
Mathias Gaunard -
Paul A. Bristow -
Peter Dimov -
Sebastian Redl