Twitter | Search | |
Roman Apr 10
Switched from Jekyll to shell script:
Reply Retweet Like
Roman Apr 10
Replying to @romanzolotarev
Reply Retweet Like
Roman Apr 10
Replying to @romanzolotarev
It took about twenty hours to replace Jekyll with a simpler solution. Tested three markdown parsers (tried to fix one of them and failed). Learned new things about about lowdown(1), awk(1), rsync(1), entr(1), find(1), and httpd(8). Cleaned up my pages.
Reply Retweet Like
Roman Apr 10
Replying to @romanzolotarev
Still using GitHub Pages for now. This is why the default destination of `ssg build` is `./docs`. To publish I run two commands instead of one: $ ssg build $ git push P.S. Yes, I know about `.git/hooks/pre-push`.
Reply Retweet Like
Roman Apr 10
Replying to @romanzolotarev
The source code is here if you're curious:
Reply Retweet Like
Roman Apr 10
Replying to @romanzolotarev
The current version regenerates all pages even only one file is changed. While I have fewer than a hundred pages, performance is not an issue, but sooner or later I'll need to fix that.
Reply Retweet Like
Tim Chase Apr 10
Replying to @romanzolotarev
See my comment about make(1) having already solved this problem 😉
Reply Retweet Like
Roman Apr 10
Replying to @gumnos
Yep, that's the plan. :)
Reply Retweet Like
Adam Dymitruk 🇨🇦 Apr 10
Replying to @romanzolotarev @gumnos
What about just testing the hash instead of relying on dates? Could leverage git itself for a report of what's changed? Or just diff?
Reply Retweet Like
Tim Chase Apr 10
while fallible, mtime is fast, using just a stat() call. Any sort of hash or diff would require scanning the actual content of the file.
Reply Retweet Like
Roman Apr 10
Replying to @gumnos @adymitruk
hashes are pretty fast too. just 0.04s for 670+ files tested both sha256 and md5 P.S. ssg parses those 670 files in 6.00s
Reply Retweet Like
Roman Apr 10
Replying to @gumnos @adymitruk
git is cool, but I'd rather keep it simple. P.S. git is not installed on by default.
Reply Retweet Like
Tim Chase Apr 11
But CVS and RCS both are… 😉
Reply Retweet Like
Roman Apr 11
Replying to @gumnos @adymitruk
I'm going there... ;)
Reply Retweet Like
Tim Chase Apr 11
I still use RCS regularly for config-files but have largely managed to avoid CVS that requires any thought/memorization (other than copy/pasting from OpenBSD man-pages/website when upgrading a -CURRENT system), skipping to svn then hg/git.
Reply Retweet Like
Roman Apr 11
Replying to @gumnos @adymitruk
I like git, but because I know nothing else ;)
Reply Retweet Like
Tim Chase Apr 11
Hah, I also had experience with MS VSS but that was a carnival of bad. I like git's internal simplicity, but the CLI UI atop it is pretty poorly thought out. Ah, well. It's my main VCS now and I've gotten used to the pain. 😉
Reply Retweet Like
Roman Apr 11
Replying to @gumnos @adymitruk
All my daily git use cases are pretty straigtforward. git init git add . -p git diff git commit git log --oneline git rebase -i ... git reset [--hard] ... git remote add origin ... git push [--set-upstream] origin master git pull git branch [-D] git merge ... git checkout ...
Reply Retweet Like
Roman Apr 12
Replying to @romanzolotarev
Dear , what is the best way to learn CVS for a git user? I've skimmed `man cvs`. Could you list your most frequently used CVS commands please?
Reply Retweet Like
Tim Chase
Dagnabbit. Now you've got me interested in (re)learning some CVS to (re)gain some proficiency at it. I thought I had one of the O'Reilly books ("Essential CVS" or "CVS Pocket Reference") in my ebook collection but apparently not. 🤔
Reply Retweet Like More