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). > > 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
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
