[Spice-devel] [PATCH v3 00/28] Win10 support patches
Frediano Ziglio
fziglio at redhat.com
Thu Sep 8 10:59:06 UTC 2016
> > 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.
Frediano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160908/3c10213c/attachment-0001.html>
More information about the Spice-devel
mailing list