On Thu, Sep 8, 2016 at 1:59 PM, Frediano Ziglio <fzig...@redhat.com> wrote:
> On 8 Sep 2016, at 12:30 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Thu, Sep 08, 2016 at 09:01:58AM +0300, Dmitry Fleytman wrote: > > > On 7 Sep 2016, at 18:49 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 06:40:57PM +0300, Dmitry Fleytman wrote: > > > On 7 Sep 2016, at 18:20 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 05:55:31PM +0300, Sameeh Jubran wrote: > > On Wed, Sep 7, 2016 at 5:47 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 04:10:18PM +0300, Sameeh Jubran wrote: > > Dmitry Fleytman (2): > Introduce end-of-line normalization > > > So it seems everything was changed from Dos to Unix? What is the > rationale for going this way rather than the other way around? > I think I would convert all source files to Dos except for the include/ > ones which are c&p'ed from elsewhere. This would make the diff much > smaller, and give us a much less polluted git history. > > > Hi Christophe, > > We prefer to have the same EOL style for all files in the repository > because > this way it is much easier to define automatic EOL conversion rules for > future commits. > > > I don't know how you intend to define these automatic EOL conversion > rules, but if this is through git hook + script, having a few exceptions > is probably not that much complicated than single EOL for the whole > repository (but I agree it's less nice). > > > They are defined already. .gitattributes file introduced by commit > that converts line endings is doing the job. > > EOL handling rules may be defined by .gitattributes on a more fine-grained > basis, > but this will introduce more code to be supported without clear advantages. > > > Yup, .gitattributes is fairly flexible. > > > > > LF has a number of advantages over CR/LF so we decided to use it. > > > Which are ? > > > LF are native for UNIX systems and tools. CR character often appears as > visible > control character in text editors on Linux, for example vi. > > > I really see that codebase as a Windows thing as I don't think it even > compiles with mingw, so I don't feel using the native *Unix* line > endings is a very compelling argument here. Especially as my vim was > able to cope with line endings just fine (it does not show control > chars, it uses the proper ending when I add a new line). > > > It probably depends on specific vi distribution or configuration as mine > behaves differently. > > Probably we use vim which has good defaults and can handle quite a lot of > encoding/ending > automatically. The old plain vi is like wanting to use notepad on Windows. > > More then editors I think git on Windows has some problems. > > > > Some originally-UNIX tools tend to convert line endings to LF event when > compiled for Windows. > For example "git send-email” that we run on Windows does this. Because of > that conversion patches > send to the mailing list did not apply as was reported by Frediano. > > > Which would be solved by a .gitattributes file regardless of which > line-ending we decide to use. > > > We believe that one big commit that converts EOL characters is an > acceptable price for future simplicity. > > > Since this is going to get in the way of git log, git blame, ... > forever, I'd try to minimize the amount of change there is.. > > > Yes, this will require an additional step for "git blame” users, > but only for those who need to drill down to the very beginnings. > EOL fixes will appear on "git log" as well, not sure if this is an issue. > > Mixing EOL styles in this repository was a mistake made from the very > beginning and it needs to be fixed, better sooner than later. > > > Mixing EOL within single files is not nice indeed. Personally I think > I'd just fix these files with mixed line endings, this makes the changes > far less invasive. > > > No problem, we will do it this way. > > > I think honestly that moving all to Unix can solve some future issue but I > don't > like too to break the history. I would prepare some patches: > - convert "binary" (utf16le encoded files that git see as binary) files to > single byte > Unix (this is part of this original patch); > - fix mixed line ending files to the nearest (currently DOS) format, > specifically: > > > On 8 Sep 2016, at 12:30 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Thu, Sep 08, 2016 at 09:01:58AM +0300, Dmitry Fleytman wrote: > > > On 7 Sep 2016, at 18:49 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 06:40:57PM +0300, Dmitry Fleytman wrote: > > > On 7 Sep 2016, at 18:20 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 05:55:31PM +0300, Sameeh Jubran wrote: > > On Wed, Sep 7, 2016 at 5:47 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 04:10:18PM +0300, Sameeh Jubran wrote: > > Dmitry Fleytman (2): > Introduce end-of-line normalization > > > So it seems everything was changed from Dos to Unix? What is the > rationale for going this way rather than the other way around? > I think I would convert all source files to Dos except for the include/ > ones which are c&p'ed from elsewhere. This would make the diff much > smaller, and give us a much less polluted git history. > > > Hi Christophe, > > We prefer to have the same EOL style for all files in the repository > because > this way it is much easier to define automatic EOL conversion rules for > future commits. > > > I don't know how you intend to define these automatic EOL conversion > rules, but if this is through git hook + script, having a few exceptions > is probably not that much complicated than single EOL for the whole > repository (but I agree it's less nice). > > > They are defined already. .gitattributes file introduced by commit > that converts line endings is doing the job. > > EOL handling rules may be defined by .gitattributes on a more fine-grained > basis, > but this will introduce more code to be supported without clear advantages. > > > Yup, .gitattributes is fairly flexible. > > > > > LF has a number of advantages over CR/LF so we decided to use it. > > > Which are ? > > > LF are native for UNIX systems and tools. CR character often appears as > visible > control character in text editors on Linux, for example vi. > > > I really see that codebase as a Windows thing as I don't think it even > compiles with mingw, so I don't feel using the native *Unix* line > endings is a very compelling argument here. Especially as my vim was > able to cope with line endings just fine (it does not show control > chars, it uses the proper ending when I add a new line). > > > It probably depends on specific vi distribution or configuration as mine > behaves differently. > > Probably we use vim which has good defaults and can handle quite a lot of > encoding/ending > automatically. The old plain vi is like wanting to use notepad on Windows. > > More then editors I think git on Windows has some problems. > > > > Some originally-UNIX tools tend to convert line endings to LF event when > compiled for Windows. > For example "git send-email” that we run on Windows does this. Because of > that conversion patches > send to the mailing list did not apply as was reported by Frediano. > > > Which would be solved by a .gitattributes file regardless of which > line-ending we decide to use. > > > We believe that one big commit that converts EOL characters is an > acceptable price for future simplicity. > > > Since this is going to get in the way of git log, git blame, ... > forever, I'd try to minimize the amount of change there is.. > > > Yes, this will require an additional step for "git blame” users, > but only for those who need to drill down to the very beginnings. > EOL fixes will appear on "git log" as well, not sure if this is an issue. > > Mixing EOL styles in this repository was a mistake made from the very > beginning and it needs to be fixed, better sooner than later. > > > Mixing EOL within single files is not nice indeed. Personally I think > I'd just fix these files with mixed line endings, this makes the changes > far less invasive. > > > No problem, we will do it this way. > > > I think honestly that moving all to Unix can solve some future issue but I > don't > like too to break the history. I would prepare some patches: > - convert "binary" (utf16le encoded files that git see as binary) files to > single byte > Unix (this is part of this original patch); > - fix mixed line ending files to the nearest (currently DOS) format, > specifically: > > > On 8 Sep 2016, at 12:30 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Thu, Sep 08, 2016 at 09:01:58AM +0300, Dmitry Fleytman wrote: > > > On 7 Sep 2016, at 18:49 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 06:40:57PM +0300, Dmitry Fleytman wrote: > > > On 7 Sep 2016, at 18:20 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 05:55:31PM +0300, Sameeh Jubran wrote: > > On Wed, Sep 7, 2016 at 5:47 PM, Christophe Fergeau <cferg...@redhat.com> > wrote: > > On Wed, Sep 07, 2016 at 04:10:18PM +0300, Sameeh Jubran wrote: > > Dmitry Fleytman (2): > Introduce end-of-line normalization > > > So it seems everything was changed from Dos to Unix? What is the > rationale for going this way rather than the other way around? > I think I would convert all source files to Dos except for the include/ > ones which are c&p'ed from elsewhere. This would make the diff much > smaller, and give us a much less polluted git history. > > > Hi Christophe, > > We prefer to have the same EOL style for all files in the repository > because > this way it is much easier to define automatic EOL conversion rules for > future commits. > > > I don't know how you intend to define these automatic EOL conversion > rules, but if this is through git hook + script, having a few exceptions > is probably not that much complicated than single EOL for the whole > repository (but I agree it's less nice). > > > They are defined already. .gitattributes file introduced by commit > that converts line endings is doing the job. > > EOL handling rules may be defined by .gitattributes on a more fine-grained > basis, > but this will introduce more code to be supported without clear advantages. > > > Yup, .gitattributes is fairly flexible. > > > > > LF has a number of advantages over CR/LF so we decided to use it. > > > Which are ? > > > LF are native for UNIX systems and tools. CR character often appears as > visible > control character in text editors on Linux, for example vi. > > > I really see that codebase as a Windows thing as I don't think it even > compiles with mingw, so I don't feel using the native *Unix* line > endings is a very compelling argument here. Especially as my vim was > able to cope with line endings just fine (it does not show control > chars, it uses the proper ending when I add a new line). > > > It probably depends on specific vi distribution or configuration as mine > behaves differently. > > Probably we use vim which has good defaults and can handle quite a lot of > encoding/ending > automatically. The old plain vi is like wanting to use notepad on Windows. > > More then editors I think git on Windows has some problems. > > > > Some originally-UNIX tools tend to convert line endings to LF event when > compiled for Windows. > For example "git send-email” that we run on Windows does this. Because of > that conversion patches > send to the mailing list did not apply as was reported by Frediano. > > > Which would be solved by a .gitattributes file regardless of which > line-ending we decide to use. > > > We believe that one big commit that converts EOL characters is an > acceptable price for future simplicity. > > > Since this is going to get in the way of git log, git blame, ... > forever, I'd try to minimize the amount of change there is.. > > > Yes, this will require an additional step for "git blame” users, > but only for those who need to drill down to the very beginnings. > EOL fixes will appear on "git log" as well, not sure if this is an issue. > > Mixing EOL styles in this repository was a mistake made from the very > beginning and it needs to be fixed, better sooner than later. > > > Mixing EOL within single files is not nice indeed. Personally I think > I'd just fix these files with mixed line endings, this makes the changes > far less invasive. > > > No problem, we will do it this way. > > > I think honestly that moving all to Unix can solve some future issue but I > don't > like too to break the history. I would prepare some patches: > - convert "binary" (utf16le encoded files that git see as binary) files to > single byte > Unix (this is part of this original patch); > - fix mixed line ending files to the nearest (currently DOS) format, > specifically: > qxldod/QxlDod.cpp, qxldod/QxlDod.h, qxldod/driver.h, > qxldod/qxldod.vcxproj > > About future/added files I would suggest to use Unix format, we can always > change > all files to Unix in the future (for instance when we'll update visual > studio basically > changing entirely the project files). > > I'll send some proposed patches. > Thanks, that would be great. We'll wait until you send them and then we'll send v4. > > > Frediano > > > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/spice-devel > > -- Respectfully, *Sameeh Jubran* *Linkedin <https://il.linkedin.com/pub/sameeh-jubran/87/747/a8a>* *Junior Software Engineer @ Daynix <http://www.daynix.com>.*
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
