On Sun, Jan 10, 2016 at 9:23 PM, Agustín K-ballo Bergé < kaballo86@hotmail.com> wrote:
On 1/10/2016 11:56 PM, Rene Rivera wrote:
On Sun, Jan 10, 2016 at 5:05 PM, Agustín K-ballo Bergé < kaballo86@hotmail.com> wrote:
On 1/10/2016 7:51 PM, Louis Dionne wrote:
Robert Ramey
writes: The extra space used seems a small price to pay for this benefit.
It's not just about extra space. Source control is for _source_ files, not generated stuff. I don't want generated files to appear in the commit history of a code branch (but another branch like gh-pages is fine).
By way of example, this is the kind of noise committing generated documentation can yield:
https://github.com/boostorg/hana/commit/e471106dc850ad72f7abaf442b3570f7f34d...
And by comparison, here's the minimal non-noise that pre-generating for Predef has: <
https://github.com/boostorg/predef/commit/009367d6a1b6a26199f5b849ea166c44cf...
.
I honestly don't get this... No source code appears to change, but the documentation somehow needs to be regenerated?
I changed predef.qbk, to document the new location of a tool.
Or does moving a .jam file to a different directory cause macros to become uppercase? Or is this commit a bunch of orthogonal changes bundled together?
Those macro changes where a result of a previous human error (the human being me.. really I'm human.. trust me). In that I forgot to regenerate the docs after merging a PR (it may have been laziness too). But the HTML changes are still minimal, and proportional to the doc/code changes.
Unless your documentation source is the HTML itself, committing documentation output will necessarily introduce noise as it modifies both the source and the target. But then we would be talking static documentation, not generated documentation.
Lost me on that. Don't know what you mean. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail