On Thu, Sep 08, 2016 at 09:01:58AM +0300, Dmitry Fleytman wrote:
On 7 Sep 2016, at 18:49 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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@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 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 evencompiles with mingw, so I don't feel using the native *Unix* lineendings is a very compelling argument here. Especially as my vim wasable to cope with line endings just fine (it does not show controlchars, 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 whichline-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 thinkI'd just fix these files with mixed line endings, this makes the changesfar less invasive.
No problem, we will do it this way.
Christophe
|