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

[Christophe Fergeau]

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

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

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160908/1c3a63f0/attachment.sig>