Log Message:
hugo: update to 0.85.0

v0.85.0
-------

Hugo 0.85.0 is on the smaller side of releases, but the main new thing it
brings should be important to those who need it: Poll based watching for file
system changes.

Hugo uses Fsnotify to provide native file system notifications. This is still
the default, but there may situations where this isn't working. The file may
not support it (e.g. NFS), or you get the "too many open files" error and
cannot or do not want to increase the ulimit. Enable polling by passing the
--poll flag with an interval:

hugo server --poll 700ms

You van even do "long polling" by passing a long interval:

hugo server --poll 24h

v0.84.0
-------

This release brings several configuration fixes and improvements that will be
especially useful for themes.

Deep merge of theme Params

One of the most common complaint from Hugo theme owners/users has been about
the configuration handling. Hugo has up until now only performed a shallow
merge of theme params into the configuration.

With that, given this example from a theme configuration:

[params]
[params.colours]
blue="#337DFF"
green="#68FF33"
red="#FF3358"

If you would like to use the above theme, but want a different shade of red,
you earlier had to copy the entire block, even the colours you're totally happy
with. This was painful even the simplest setup.

Now you can just override the params keys you want to change, e.g.:

[params]
[params.colours]
red="#fc0f03"

For more information, and especially about the way you can opt out of the above
behaviour, see Merge Configuration from Themes.

Themes now support the config directory

Now both the project and themes/modules can store its configuration in both the
top level config file (e.g. config.toml) or in the config directory. See
Configuration Directory.

HTTP headers in getJSON/getCSV

getJSON now supports custom HTTP headers. This has been a big limitation in
Hugo, especially considering the Authorization header.

New erroridf template func

Sometime, especially when creating themes, it is useful to be able to let the
user decide if an error situation is critical enough to fail the build. The new
erroridf produces ERROR log statements that can be toggled off:

{{ erroridf "some-custom-id" "Some error message." }}

Will log:

ERROR: Some error message.
If you feel that this should not be logged as an ERROR, you can ignore it by \ 
adding this to your site config:
ignoreErrors = ["some-custom-id"]