Replace commit feed aggregation with manual import

This is the starting point for extending _Overview_ to support various
types of recent updates (i.e. not just blog articles and commits over a
certain message size).

While direct fetching and rendering of markdown-formatted Git commit
messages is an attractive concept, this new approach should be much more
flexible. As a side benefit commit entries can now be edited and
expanded compared to their fixed Git reference. e.g. retroactively
expanding upon older commits or adding example media that doesn't
strictly belong inside the actual commit message.

1 files changed, 20 insertions, 0 deletions

diff --git a/source/00_content/commits/change/2016_02_14_20_52_1ffaf37388cd691e88196b6e00455eda0e652cf0.md b/source/00_content/commits/change/2016_02_14_20_52_1ffaf37388cd691e88196b6e00455eda0e652cf0.md
new file mode 100644
index 0000000..e7ee30b
--- /dev/null
+++ b/source/00_content/commits/change/2016_02_14_20_52_1ffaf37388cd691e88196b6e00455eda0e652cf0.md
@@ -0,0 +1,20 @@
+# Implement support for excluding arbitrary paths from tracking
+
+The library may be provided with a new-line separated list of regular expressions via the newly introduced `CHANGE_LOG_IGNORE_PATTERN_PATH`.
+
+Any proposed tracking path that is matched by any of the provided patterns is excluded from change reporting. This functionality uses the Standard's regular expression parsing functionality and as such doesn't introduce any new dependencies. If no file path is provided or the provided file path is unreadable all paths will be tracked.
+
+`change` was adapted to set `CHANGE_LOG_IGNORE_PATTERN_PATH` to `.change_log_ignore` which means that it will by default exclude any patterns provided via this file in the current working directory.
+
+An example for such a file customized for hiding _vim_'s internal write
+logic may look as follows:
+
+	[0-9]+
+	[^~]*~
+	[.*\.viminfo
+	.*\.swp
+
+Note that this is implemented in a fashion where it is not guaranteed that the full _canonical_ path is checked against the patterns. It remains to be decided if this is enough for all common use cases of this new functionality.
+
+`tracking::PathMatcher` lacks any explicit thread synchronization - according to my current knowledge this should not be necessary as we are only ever reading the private `std::vector<std::regex>` instance.
+If invalid regular expressions are provided they are silently ignored.