Should SecondsSinceUnixEpoch be i64 instead of u64?

[metatoaster]

I noted in commit 4bc0ae1 that it was changed from the original u32 into u64 now, but I can't help but wonder why not follow libgit2 in using int64_t instead? While I will acknowledge that the official Git client also use the unsigned int type, it doesn't make sense as i64 is plenty big enough enough for billions of years into the future already, that the format does not exclude the ability for backdated commits before the unix epoch (related StackOverflow thread), and that there exists efforts that make use of git commits using historical dates. For example, an archive of all French Civil Codes use backdated commits starting from 1800s), like this particular commit:

$ git cat-file -p c4f352ab34c8a707cbbcb9853ab4d3cf096beb03
tree b21de8747b60ebbc0ef90b2046daaf4ac4bb6288
parent af72ddbd30e21fe8596c0ec8e2f4f92426e3f8de
author Législateur <> -5263747740 +0009
committer Législateur <> -5263747740 +0009

Version consolidée au 15 mars 1803
$ date -u -d @-5263747740
Mon 14 Mar 1803 23:51:00 UTC

Naturally, the default git client simply truncate the date to 0 so showing that as if it was "committed" at the Unix Epoch, which is wrong.

Anyway, gix as a whole is a lot more complete than I thought, and in fact quite usable as a libgit2 replacement for many low level features, but the lack of documentation (well, it's a work in progress, but I mean more a lack of code comment referencing similar API to libgit2) is a significant pain point, especially coming in from libgit2 where things like revparse_single was the spelling and it took me two days to find the equivalent (as gix::Repository::rev_parse_single() - I later git grep rev-parse as per the git rev-parse command and that finally lead somewhere - tunnel visioned from using the API too exclusively), so thankfully I didn't end up thinking I need to write that feature and later find that it already exists... but I digress now.

[Byron]

That's a great idea, I simply didn't think of that as a use-case and followed git, but agree that dates prior to UNIX epoch should be easily supported by making the type i64 instead. It's worth nothing that the commit-graph data structure won't support that, but it should be possible to handle it gracefully - the current implementation has the advantages of using u64 consistently in all places.

I will be addressing that and validate it actually works with dates using the repository you linked.

---

The other topic about discoverability is an interesting one - admittedly I didn't yet try to make that easy, but believe it's merely about getting started and maintaining a list consistently. From that point on, gix will be easier to use and migrate to.

I will be setting up a document for that that is easy to discover, maintain and contribute to.

Thanks for all your feedback, I will post here for updates.

[Byron]

All changes were implemented in this PR. A new release is in the making.

[metatoaster]

I do understand how the project is still growing and that keep up with documentation at this stage is a huge pain point from the developer/maintainer point of view, so I fully understand the difficulty in that.

That being said, I think introducing additional examples will be a useful first steps in providing discoverability - given that I just finished a way to extract logs, I could extract the relevant bits and convert that into a standalone example. This might take me a bit of time but if examples like this are something welcomed I will make a pull request at some point.

[Byron]

More example programs are definitely welcome, and I am looking forward to it :).

[Byron]

Here is the new release by the way..