Запиля́в собі стрьомну автоматиза́цію для кращого контролю за датою оновлення публікацій.
Можли́во, через пару днів подивлюся на це все і вирішу, що то є стрьо́мна чортівня́. Але поки мені подобається і поки я в цій схемі не бачу явних вад.
Оновлено: ну, точніше, це краще ніж нічого.
Про що мова
Цілком природньо, що у кожної сторінки (в даному випадку у кожного посту́) є дата створення, тобто момент часу, коли пост був створений чи опублікований (вважа́тимемо це одни́м і тим же). Це те, що Jekyll очікує побачити у полі date десь у front matter.
Але, також цілком природньо, кожну сторінку я можу оновити: виправити помилки, дописа́ти постскриптум, або типова для цього блоґа фішка — послухати, як ця сторінка звучить через синтез мовлення, і додати наголоси. І це буде дата останньої модифікації. Стандартного такого поля у Jekyll не передбачено. Я вирішив назвати це по́ле mtime.
Обидві дати важливі. Обидві дати потрібні. В хронологічному порядку пості́в (і навіть в URL) використовується дата створення. Але в RSS/Atom та в sitemap треба використовувати дату останнього оновлення.
Як воно працю́є
Задум такий. Команда make post_checkout оновлює дату останньої модифікації файлу (тобто у файловій системі) у відповідності до моменту часу останнього коммі́ту в цей файл, крім тих коммі́тів, у яких commit message співпадає зі спеціа́льною магічною константою Fix mtime.
Далі. Команда make mtime оновлює по́ле mtime (або створює його) у front matter до значення, що співпадає з датою останньої модифікації файлу.
Що не працює
Ще не придумав, як краще зробити синхроніза́цію дати коммі́та і значення по́ля mtime всередині файлу. Ну, завжди можна зробити два коммі́та: один який треба, другий Fix mtime, хоч це і тупо. Але, можливо, краще mtime оновлювати через pre-commit hook.
Оновлено: або спробую міняти дату коммі́ту на потрібну через git commit --amend.
git commit --amend --date "`git diff HEAD^ HEAD | grep '^+mtime:' | cut -c9-`"
Можливо, мій інструмент для публікації варто трохи полі́пшити, щоб він робив git commit --date="..." для кожного нового посту́. Треба виключити ризик виникнення ситуацій, коли дата поста і дата коммі́та відрізняються на одну-дві секунду.
Оновлено: як тимчасовий workaround, я десь в шабло́нах місцями ігнору́ю mtime, що відрізняється від дати створення менш ніж на годину.
А от команда make post працює інакше, вона створює шаблон з вже вказаною датою. Потім я в цей шаблон додаю́ свій текст, а дата лишається старою. Можливо, тут треба додаткову автоматизацію — наприклад таку, яка вже є в make pub. Зараз я оновлю́ дату вручну і зроблю коммі́т з ключем --date="...", але це криво.
Далі буде.