Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/35
I'll rebase this after #36 and #37 have been processed.
---
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
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
Replaced by #37
---
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
GitHub user JJoe2 opened a pull request:
https://github.com/apache/log4net/pull/37
Implement flushing of appenders that buffer data
Replaces #25
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/JJoe2/log4net wip/Flush
[
https://issues.apache.org/jira/browse/LOG4NET-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15578731#comment-15578731
]
ASF GitHub Bot commented on LOG4NET-511:
Github user JJoe2 closed the pull request at:
Github user JJoe2 closed the pull request at:
https://github.com/apache/log4net/pull/25
---
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
GitHub user JJoe2 opened a pull request:
https://github.com/apache/log4net/pull/36
Use UTC internally to avoid ambiguous timestamps
Resubmitting replacement for #24
Rebased to latest trunk and fixed backwards compatibility issue of binary
serialization of LoggingEvent.
What do you think of adding a timezone field such that people can calculate
the utc timestamp if they care? Nothing breaks while all usecases are taken
care of.
On 15 Oct 2016 7:23 p.m., "Dominik Psenner" wrote:
I highly recommend to stay compatible and add a utc timestampas
I highly recommend to stay compatible and add a utc timestampas a new field
and deprecate the old field for at least one release cyle.
On 15 Oct 2016 7:20 p.m., "JJoe2" wrote:
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
Thanks.
I agree that I should have done a better job of keeping these changes
separate but when I did the initial work I was very much a git novice.
Iâll bite the bullet and separate
[
https://issues.apache.org/jira/browse/LOG4NET-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved LOG4NET-512.
Resolution: Fixed
Fix Version/s: 2.0.6
should be fixed with an adapted version of
Github user bodewig commented on the issue:
https://github.com/apache/log4net/pull/25
@JJoe2 I'm sorry, but now the patch contains all the changes we've made
since you started your branch. It would be good if you could rebase your branch.
Many thanks for the `w=1` trick, I
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
From your remarks I gather you arenât too concerned about line ending
inconsistencies.
And since I did a bit of research today, and discovered that itâs
possible to ignore whitespace /
Github user bodewig commented on the issue:
https://github.com/apache/log4net/pull/25
To be honest I have no idea how svn line ends transfer to the git mirror.
In svn line ends are CRLF on Windows and LF on Unix. What git makes from this
depends on your `autocrlf` config and probably
Github user JJoe2 commented on the issue:
https://github.com/apache/log4net/pull/25
Some recent commits have changed line endings from LF to CRLF: some of the
ones that affect me are listed below. Would it be possible for you to fix
these line endings in the trunk? This will make
14 matches
Mail list logo