[boost] Git Modularization hiccups
77 views
Skip to first unread message
Beman Dawes
May 23, 2013, 6:12:44 PM5/23/13
to Boost Developers List
* "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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Dave Abrahams
May 24, 2013, 12:37:32 AM5/24/13
to bo...@lists.boost.org
on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
> * "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'
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.
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.
--
Dave Abrahams
Lars Viklund
May 24, 2013, 1:10:46 AM5/24/13
to bo...@lists.boost.org
On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
>
> on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> 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
>
> on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> 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
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.
--
Dave Abrahams
May 24, 2013, 2:00:19 AM5/24/13
to bo...@lists.boost.org
on Thu May 23 2013, Lars Viklund <zao-AT-acc.umu.se> wrote:
> On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
>>
>> on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> 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?
out more?
--
Dave Abrahams
Lars Viklund
May 24, 2013, 2:17:49 AM5/24/13
to bo...@lists.boost.org
On Thu, May 23, 2013 at 11:00:19PM -0700, Dave Abrahams wrote:
>
> on Thu May 23 2013, Lars Viklund <zao-AT-acc.umu.se> wrote:
>
> > On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
> >>
> >> on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> 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
>
> on Thu May 23 2013, Lars Viklund <zao-AT-acc.umu.se> wrote:
>
> > On Thu, May 23, 2013 at 09:37:32PM -0700, Dave Abrahams wrote:
> >>
> >> on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> 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?
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 | z...@acc.umu.se
Paul A. Bristow
May 24, 2013, 5:03:48 AM5/24/13
to bo...@lists.boost.org
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
pbri...@hetp.u-net.com
Mathias Gaunard
May 24, 2013, 5:56:19 AM5/24/13
to bo...@lists.boost.org
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
> 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.
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
>
>
> 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
> I hope we will have all of these - and more - including .sh and .bat.
useful ones in that list.
*.bat and *.cmd could be useful, but the value in svn props is wrong, it
should force to CRLF.
Paul A. Bristow
May 24, 2013, 6:57:28 AM5/24/13
to bo...@lists.boost.org
> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Mathias Gaunard
> Sent: Friday, May 24, 2013 10:56 AM
> To: bo...@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?
>
> > 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.
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.
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
pbri...@hetp.u-net.com
Jonathan Wakely
May 24, 2013, 7:10:40 AM5/24/13
to bo...@lists.boost.org
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
>>
>> 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?
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.)
Peter Dimov
May 24, 2013, 7:26:10 AM5/24/13
to bo...@lists.boost.org
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.
> 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
May 24, 2013, 7:31:25 AM5/24/13
to bo...@lists.boost.org
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
> 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.
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.
Sebastian Redl
May 24, 2013, 7:33:59 AM5/24/13
to bo...@lists.boost.org
On 2013-05-24 13: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.
And if you forget, you have one very popular code editor that preserves
> 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.
line endings on copy&paste, leaving you with files with mixed line endings.
Mathias Gaunard
May 24, 2013, 8:05:59 AM5/24/13
to bo...@lists.boost.org
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
> 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.
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.
Mathias Gaunard
May 24, 2013, 8:07:22 AM5/24/13
to bo...@lists.boost.org
On 24/05/13 13:33, Sebastian Redl wrote:
> On 2013-05-24 13: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.
> And if you forget, you have one very popular code editor that preserves
> 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.
> On 2013-05-24 13: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.
> And if you forget, you have one very popular code editor that preserves
> line endings on copy&paste, leaving you with files with mixed line endings.
Unfortunately, many developers don't seem to even review their own sets
of changes before committing them.
Peter Dimov
May 24, 2013, 8:27:00 AM5/24/13
to bo...@lists.boost.org
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
> 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.
when, for example, some lines end with a backslash - only the CR is escaped.
Richard
May 24, 2013, 9:31:22 AM5/24/13
to bo...@lists.boost.org
[Please do not mail me a copy of your followup]
bo...@lists.boost.org spake the secret code
<006101ce585d$9e765100$db62f300$@hetp.u-net.com> thusly:
># Data formats
>*.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>
bo...@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
>[...]
>*.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
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>
Richard
May 24, 2013, 9:37:29 AM5/24/13
to bo...@lists.boost.org
<A95078DB6C254A14BFEE61FE38AABFEC@pdimov5> thusly:
>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>
>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.
"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>
"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>
Dave Abrahams
Jul 15, 2013, 11:36:07 AM7/15/13
to bo...@lists.boost.org
on Thu May 23 2013, Beman Dawes <bdawes-AT-acm.org> wrote:
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
Reply all
Reply to author
Forward
0 new messages