[Spice-devel] [PATCH v3 00/28] Win10 support patches

Thu Sep 8 11:05:13 UTC 2016

On Thu, Sep 8, 2016 at 1:59 PM, Frediano Ziglio <fziglio at redhat.com> wrote:

> On 8 Sep 2016, at 12:30 PM, Christophe Fergeau <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 <cfergeau at 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 at 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>.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160908/f61e6da1/attachment-0001.html>