There are definitely some quirks here re: author vs. committer, and the potential for commits to change due to cherry-picking, etc. Hopefully I don't make that much of a mess of the repo, though, as it's just me committing to it. But if I do, you can bet there'll be another blog post about what I learned from fixing it!
My biggest concern would be having to put the date back into the frontmatter to implement drafts (with a future date) - i.e. the oldest "author date" would no longer imply "publish date".
The way I'm doing drafts right now is prepending wip- to the filename, and .gitignore-ing blog/wip-*. That means that drafts aren't under version control. This is fine for me (for now) because usually I have zero or one drafts at any given time.
Bringing drafts into version control is an interesting problem. As you say, it would require basically throwing out the idea that first commit == published date. Maybe a drafts directory is the easiest way to go? git log <filename>doesn't follow file renames by default (see --follow), so moving a file from drafts/ to blog/ could essentially be the "trigger" for publication.
Interesting stuff. Thanks for pointing this out!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are definitely some quirks here re: author vs. committer, and the potential for commits to change due to cherry-picking, etc. Hopefully I don't make that much of a mess of the repo, though, as it's just me committing to it. But if I do, you can bet there'll be another blog post about what I learned from fixing it!
My biggest concern would be having to put the date back into the frontmatter to implement drafts (with a future date) - i.e. the oldest "author date" would no longer imply "publish date".
The way I'm doing drafts right now is prepending
wip-to the filename, and.gitignore-ingblog/wip-*. That means that drafts aren't under version control. This is fine for me (for now) because usually I have zero or one drafts at any given time.Bringing drafts into version control is an interesting problem. As you say, it would require basically throwing out the idea that first commit == published date. Maybe a
draftsdirectory is the easiest way to go?git log <filename>doesn't follow file renames by default (see--follow), so moving a file fromdrafts/toblog/could essentially be the "trigger" for publication.Interesting stuff. Thanks for pointing this out!