On Wed, Sep 07, 2016 at 06:40:57PM +0300, Dmitry Fleytman wrote:
On 7 Sep 2016, at 18:20 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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@xxxxxxxxxx>
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 conversionrules, but if this is through git hook + script, having a few exceptionsis probably not that much complicated than single EOL for the wholerepository (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.
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.
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.
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.
Christophe