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

[Dmitry Fleytman]

> 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.

> 
>> 
>> 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.

> 
> Christophe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160908/310da4ea/attachment-0001.html>