i.e. state the intent.
One reason to steer clear of inline anonymous functions.
So What Happened?
I'm not convinced this has anything to do with sorting.
I could be wrong but I think there's some ambiguity when it comes to Simple Git's API (TypeScript or not). It mostly defers to the git log documentation (and Pretty Formats).
When =<format> part is omitted, it defaults to medium.
If Simple Git follows the Git convention then date would be "Author date". The "commit date" is only available with the fuller format as CommitDate or committer date.
(edit: it is the author date; the "commit date" requires a custom format option with Simple Git).
You may be wondering what the difference is between author and committer. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work
So date may actually be the "Author Date" which may be good enough for your purposes as it refers to the time of git commit. But the actual "commit date" can be altered by other operations.
So if you need sorting by "author date" then perhaps an explicit sort may be the "safer" route.
This seems to be more related to (mis)understanding the data being manipulated/relied on. If anything, it demonstrated again how "naming things is hard".
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.
If you need to rely on memorization:
compare(a,b) > 0
thenb
beforea
knowing that
t1 = "cherry", t2 = "apple"
'c' - 'a' > 0
i.e. "apple" before "cherry"t1 = 42, t2 = 2112
t2 - t1 > 0
i.e.2112
before42
Is this painful?
Sure, hence
i.e. state the intent.
One reason to steer clear of inline anonymous functions.
I'm not convinced this has anything to do with sorting.
I could be wrong but I think there's some ambiguity when it comes to Simple Git's API (TypeScript or not). It mostly defers to the git log documentation (and Pretty Formats).
So given the amended code:
it seems to be more a misunderstanding of the data that is being returned by the API.
Also given the way Simple Git depends on the Git documentation the
date
property name is tricky.Commit Formatting
If Simple Git follows the Git convention then
date
would be "Author date". The "commit date" is only available with thefuller
format asCommitDate
orcommitter date
.(edit: it is the author date; the "commit date" requires a custom
format
option with Simple Git).Viewing the Commit History
So
date
may actually be the "Author Date" which may be good enough for your purposes as it refers to the time ofgit commit
. But the actual "commit date" can be altered by other operations.So if you need sorting by "author date" then perhaps an explicit sort may be the "safer" route.
This seems to be more related to (mis)understanding the data being manipulated/relied on. If anything, it demonstrated again how "naming things is hard".
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
drafts
directory 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!