Github user JJoe2 commented on the issue:
Iâve just fetched the latest trunk into my fork.
As far as I see there are still some line-end inconsistencies in the git
For example core/LoggingEvent.cs has CRLF endings while other files such as
core/LogImpl.cs have LF endings.
My understanding is that LF is preferred, so I have configured my git with
autocrlf to true.
To handle the inconsistencies I can envisage the following approaches
1. Push everything with LF and leave you to deal with inconsistencies
such as LoggingEvent.cs
2. Whenever I see a file with CRLF, push a commit that fixes this by
changing to LF, then a second commit with my changes.
Do you have a preference, or a better suggestion?
From: Stefan Bodewig [mailto:notificati...@github.com]
Sent: 13 October 2016 07:58
Cc: JJoe2; Author
Subject: Re: [apache/log4net] API to flush appenders that buffer logging
I've ensured all line-ends are consistent and set to native in svn trunk -
git is not our primary repository,
https://svn.apache.org/repos/asf/logging/log4net/trunk/ is. If you've got
access to svn maybe it is a better idea to develop your patch against it and
attach it to JIRA. Using the traditional way :-)
I'd really prefer we don't add any new methods to existing interfaces as
this may break custom implementations. That's why I didn't want Flush in
ILoggerRepository. We can't know who has implemented the interface in library
or application code. LoggerManager could check whether ILoggerRepository
implemented IFlushable and simply don't do anything in its Flush implementation
if it didn't.
You are receiving this because you authored the thread.
Reply to this email directly, view it on
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket