diff --git a/etc/yearlies/2022.md b/etc/yearlies/2022.md new file mode 100644 index 00000000000..2f7e75d9c92 --- /dev/null +++ b/etc/yearlies/2022.md @@ -0,0 +1,62 @@ +And 365 days later as of 2022-12-31, we are counting **106.492 SLOC (up by 44.354) and 170.544 lines total (up by 83.204 mostly due to auto-generated changelogs)** in **9.988 commits (up by 4.317)**. There are **51 crates (up by 24)** and 4 binaries, with`ein` and `gix` as part of `gitoxide` and `cargo smart-release` and `cargo-changelog` as part of tooling. There are **57 unique authors (up by 36)**. This means ~121 lines per day (down by 52) in ~12 commits each day (up by 1). On GitHub there are **5165 stars (up by 2386)** for ~6.5 stars per day. + +The tool invocation `ein tools estimate-hours` now rates the project cost at **6822 hours (up by 3199) or ~853 in 8 hour working days**, for an average working time of **8.8 hours in the past 365 days**. My timetracker reveals that I **spent 1231h on open source work** which is dominated by `gitoxide` and which is supported [_via GitHub sponsors_](https://github.com/sponsors/Byron). **136h were for paid closed-source work and consulting**, whereas **the Rust Foundation grant motivated 460h** to improve `gitoxide` and drive grant-goals forward. The **total is 1828 hours worked** which boils down to **5 hours of work per day (35h per week)**. Coincidentally, this is inline with [my prediction from last year](https://github.com/Byron/gitoxide/discussions/285) where I was hoping for 5h per day of sustained work. More importantly, it is financially sustainable at a little more than two times the German minimal wage per net per hour. + +Thus far, **I have dedicated the last 989 days to getting `gitoxide` off the ground**, and I feel **it's finally breaking through** 🎉. + +### What's planned for 2023 + +The [`cargo` integration](https://github.com/rust-lang/cargo/pull/11448) will be the main driver in terms of features which should make `gitoxide` feasible for a great variety of projects. The anticipated feature-set would include… + +- a GitHub action for faster clones and checkouts +- shallow clones +- fully functional worktree checkout and reset (with filters) and submodules +- native support for `git upload-pack` which would also be a building block for a git server +- a native `ssh` transport +- worktree status +- add worktree files to index and create a tree + commit + +Probably we should add `push` support for good measure to complete everything related to transport git repositories over the wire. It would be an incredible feat to also have a first integrated `git` server up and running, on the level of `git-daemon` at least with options to turn it into a customisable HTTP server as well, even though it seems unlikely there is enough time for that. + +In order to achieve all of the above, I hope that I can increase my sustained daily effective work time to 6h per day for 2190ish hours in total. + +### Some words of Gratitude + +By now I am able to humbly sustain myself and my family while following my calling, and for that I am incredibly grateful - I simply couldn't imagine a better use of my (life)time. Doing so would not be possible without the generosity of my sponsors: thank you, thank you so much! + +This year also brought more contributions than ever before, and I am thankful for every single one of them, be it PRs with fixes and improvements, or discussions to help me see the problems `gitoxide` has to solve. Thank you for your contributions! + +There are a few people and entities I would like to call out specifically this year, it's definitely personal :). + +#### Thank you, Josh! + +[Josh Triplett](https://joshtriplett.org/), a well-known member of the Rust community, back in May 2021 suggested to turn on the GitHub sponsorship feature to become my first sponsor, and start making `gitoxide` financially sustainable. He supported me ever since in more ways than I can count and definitely changed my life to the better, having been incredibly impactful with maybe a few well-placed nudges here and there. `gitoxide` wouldn't be what it is today without him, and I am deeply grateful for that. + +Let's make it happen in 2023 :)! + +#### Thank you, Paul, of Codebase! + +Earlier this year Paul approached me about bringing `git` onto the internet computer, an endeavour which since has resulted in the launch of [codebase.org](https://codebase.org). Thanks to him, `gitoxide` get's to go where no `git` has gone before, and to me the most notable artifact of our collaboration is the `max-pure` build target that became possible thanks to the sponsored `reqwest` HTTP transport. Thank you, Paul, for providing such a valuable perspective, and I am curious what 2023 brings :). + +#### Thank you, Cargo team! + +Even before `gitoxide` arrived in `cargo` I was implementing [my first `cargo` feature](https://github.com/rust-lang/cargo/pull/9992) thanks to the sponsorship of Profian that was arranged by, you guessed it, Josh Triplett. That was were I met the fine folks of the Cargo team whose humble and kind reviews are aspirational for the `gitoxide` project by now. Thank you all, for handling everyone's PRs the way you do, I absolutely appreciate your time and value every interaction. + +I hope in 2023 we can bring `cargo` to new heights together :). + +#### Thank you, Docs.rs team! + +In 2022 I became a member of the docs.rs team - it all happened so fast! And as member of the team, we managed to lift the `crates-index-diff` crate that powers `docs.rs`'s build triggers onto a new quality level by bringing in `gitoxide` and an entirely new diffing engine. The latter wouldn't have been possible without the incredible work of [Pascal Kuthe](https://github.com/pascalkuthe), and I hope that won't be the last time we can excel together. +Now that the dust has settled I feel I can slowly grow into the docs.rs team, learn from its members and see how critical infrastructure is run in an open-source environment. Thanks for having me, I hope I can meet you one day. + +#### Thank you, Rust Foundation! + +With every breath I am turning `gitoxide` into _foundational_ software that is not only powering a growing number of applications but one day critical infrastructure as well. This year, the Rust Foundation provided grants to finance the development of `gitoxide` and its integration into existing software, and by continuing to do so it is a pillar of sustainable development. Thank you for your trust! + +It is my hope that as the Rust Foundation evolves, it can help `gitoxide` to become more community driven without an over-reliance on a single person. + +Have a great year 2023! + +---- + +Thanks for reading, let's make 2023 a great year for everyone :)! diff --git a/etc/yearlies/2023.md b/etc/yearlies/2023.md new file mode 100644 index 00000000000..5bd08c65e2d --- /dev/null +++ b/etc/yearlies/2023.md @@ -0,0 +1,174 @@ +##### The year in numbers + +And 365 days later as of 2023-12-31, we are counting **141,005 SLOC, up by 34,513**, which is 75% *of the year before* (➡*OTYB*) in **13,002 commits up by 3,014** and 70%OTYB. There are **62 crates (up by 11)** and 2 binaries, with `ein` and `gix` as part of `gitoxide`. There are **105 unique authors (up by 48 and 133%OTYB)**. This means ~95 lines per day in ~8 commits each day. On GitHub there are **7,266 stars (up by 2,101 which is 88%OTYB)** for ~5.8 stars per day. + +The tool invocation `ein tool estimate-hours` now rates the project cost at **8736 hours (up by 1914) or ~1092 x 8 hour working days**, for an average working time of **5.24 hours in the past 365 days**. + +My timetracker reveals that I **spent 1576h on open source work** which is dominated by `gitoxide` and which is supported [_via GitHub sponsors_](https://github.com/sponsors/Byron) at 997h. **469h were for commercial work and consulting**. **The grant of the Rust Foundation grant motivated 241h** to improve `gitoxide` and drive grant-goals forward. The **total of 2045 hours worked** boils down to **5.6 hours of work per day (39.2h per week)**, 112%OTYB. + +My open-source work is financially sustainable at 2.5 times the German minimal wage net per hour, or 125%OTYB *(note that there is also income through commercial work which isn't included in this value)*. + +Thus far, **I have spent the last 1354 days to getting `gitoxide` off the ground**, and it's still quite far from even reaching parity with `git2`. + +### What was planned for 2023 - a retrospective + +There was a (probably unreasonably long) list of items to be done in 2023, let’s have a look to see what actually happened. + +##### The previous list + +- [ ] a GitHub action for faster clones and checkouts + - I didn’t even work on it probably out of fear it opens up a rabbit hole of massive proportions, and it was easy to rationalise it further by saying that it’s good to not spread `gix` even more and deal with the additional support this would entail. + - I still think it’s absolutely worth doing though. +- [x] shallow clones +- [x] fully functional worktree checkout and reset (with filters) and submodules + - It was quite a bit of work to implement everything that was needed, like attributes, filters, pathspecs. + - Submodule handling during checkout isn’t actually implemented, but submodules can be read and traversed and with that it should be quite straightforward to add this capability. +- [ ] native support for `git upload-pack` +- [ ] a native `ssh` transport + - I am absolutely not looking forward to this one as it will need me to dabble in FFI and a lot of `unsafe`, but it's a requirement for `cargo`. +- [x] worktree status (*partial*) + - index-to-worktree diffs are actually implemented and seem production ready, but additional pieces of a full status are still missing. +- [ ] add worktree files to index and create a tree + commit + +It does look like only about 40% have been achieved, or less, but I also think that the list was meant to be more of a wish-list than anything that could be reasonably be achieved. + +[Last year I said](https://github.com/Byron/gitoxide/discussions/681) right below the list: + +> In order to achieve all of the above, I hope that I can increase my sustained daily effective work time to 6h per day for 2190ish hours in total. + +Not too bad, the actual value is 5.6h per day which could generously be rounded. It's clear though that even with that additional time these lofty goals would not have been achieved. + +### What's planned for 2024 + +Having learned from last year, I will do my best to keep the list of this year (*more*) reasonable and achievable. + +* complete worktree status +* basic worktree reset +* add worktree files to index and create a tree + commit +* Clone by hard-link +* support for built-in `file://` protocol + +With the above, all of `git2` in `cargo` could be replaced with `gix`, while at the same time moving `gix` up to near feature parity with `git2`. When that comes through it's probably time for a stable release, which in itself is a massive undertaking that's not possible with the way `gix` is currently built. + +Nonetheless, looking at this list along with the major progress with the `cargo` integration that it enables makes me very happy and excited for what's to come :). + + +### Some words of Gratitude + +By now I am able to sustain myself and my family while following my calling, and for that I am incredibly grateful - I simply couldn't imagine a better use of my (life)time. Doing so would not be possible without the generosity of my sponsors: thank you, thank you very much! + +Judging by the 48 new contributors, this year brought even more contributions than the previous one, and I am thankful for every single one of them, be it PRs with fixes and improvements, or discussions to help `gitoxide` become more useful and usable. + +Additionally I'd like to call out the contributed [OSS-fuzzing support](https://oss-fuzz.com) which has found many bugs already and hopefully keeps finding more due to ever-increasing (and contributed) coverage. Thanks so much! + +There is one person and entities I would like to thank individually just like last year :). + +#### Thank you, Josh! + +[Josh Triplett](https://joshtriplett.org/), back in May 2021 became my first sponsor and *patron*, which did no less than change my life to be able to follow my calling. `gitoxide`, me and my family wouldn't be what they are today without him, and I am deeply grateful for that. + +As if this wasn't enough, we doubled-down on [`buildit`](http://buildit.dev), making incredible strides, and I remain hopeful that 2024 will be the year "to make it happen" :)! + +#### Thanks, Radworks! + +[Radworks](https://radworks.org) is dedicated to cultivate internet freedom. They created a peer-to-peer network for code collaboration based on Git, which is the reason we touched base back in 2021. + +Two years later they are back, this time with a peer-to-peer fund sharing and splitting solution that `gitoxide` is an early benefactor of, and so much so that its future is secured just by that alone. + +I am unlikely to be able to thank them enough, but will try by making `git2` a dependency they won't need anymore. + +#### Thank you, Cargo team, for bearing with me! + +It's taking me years to finish the integration work and implement all features needed to fully replace `git2` in `cargo`, and yet the `cargo` team stays onboard with this work! + +Thanks so much, but… I will need just a little more time 😅. + +#### Thank you, Rust Foundation! + +With every breath I am turning `gitoxide` into _foundational_ software that is not only powering a growing number of applications but one day critical infrastructure as well. This year, the Rust Foundation kept providing a grant to finance the development of `gitoxide` and its integration into existing software, and has been a pillar of sustainable development. Thank you again for your trust! + +It is my hope that as the Rust Foundation evolves, it can help `gitoxide` to become more community driven without an over-reliance on a single person. + +#### Thanks Everyone + +It’s very likely that I failed to call *you* out for no other reason than swiss-cheese like memory, so let me thank you for the net-positive interactions we undoubtedly had. + +Let’s do that again in 2024 :)! + +---- + +🎉🎉🎉 Thanks for reading, let's make 2024 a great year for everyone :)! 🎉🎉🎉 + +---- + +### Q&A + +#### Why did the development velocity decrease? + +The pure line-of-code produced is down by 25% and the amount of commits is down by 30%. They might be correlated, even though I'd think that [Stacked Git](https://stacked-git.github.io) is the main reason for the reduction in commits. + +As for the reduced amount of code, I *think* that overall it's not less, but more or less the same. It might be that most of the 'missing' code is in commercial projects or went into `git2->gix` conversions. Of course, having a 140k SLOC project should make development slower, but as most code is still written from scratch I think the effects of the amount of code are small. Having tests for everything also is a key-enabler for fearless changes, and so is Rust. + +Maybe it's just a feeling, but I do think that the problems to solve are getting more complex as well, and I feel I have to research more to grasp how to implement a certain Git capability. That probably contributes to taking quite a bit longer. + +#### Will `gitoxide` ever be done? + +Yes, definitely! Even though done won't mean absolute feature parity with Git, as I only plan to implement what's immediately useful to me and most others. + +Knowing my velocity in lines of code and the size of `libgit2` and Git respectively, a silly estimation would be that it takes another 2 to 3.5 years for `gitoxide` to be complete. Stabilising `gitoxide` in 2 years would definitely be swell! + + +
Data + +##### State +``` +❯ git rev-parse @ +c3983c6b8d63d85ec713ae8d661723f9cf0bd55b +``` + +##### commit count +``` +❯ git log --graph --pretty="%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%ar) %C(bold blue)<%an>%Creset"' | wc -l + 13002 +``` + +##### Linecount + +``` +=============================================================================== + Language Files Lines Code Comments Blanks +=============================================================================== + JSON 1 7 7 0 0 + Makefile 1 158 112 10 36 + Shell 134 7358 5995 283 1080 + SVG 1 1 1 0 0 + Plain Text 29 637 0 504 133 + TOML 90 3628 2606 425 597 +------------------------------------------------------------------------------- + Markdown 86 61714 0 47401 14313 + |- Python 1 10 6 2 2 + |- Shell 2 8 7 1 0 + (Total) 61732 13 47404 14315 +------------------------------------------------------------------------------- + Rust 1203 157566 141005 1408 15153 + |- Markdown 746 14442 2 12343 2097 + (Total) 172008 141007 13751 17250 +=============================================================================== + Total 1545 231069 149726 50031 31312 +=============================================================================== +``` + +##### Authors + +``` +❯ ein t h + 15:55:46 traverse commit graph done 11.9k commits in 0.11s (113.6k commits/s) + 15:55:46 estimate-hours Extracted and organized data from 11935 commits in 63.375µs (188323472 commits/s) +total hours: 8736.36 +total 8h days: 1092.04 +total commits = 11935 +total authors: 108 +total unique authors: 105 (2.78% duplication) +``` + +
\ No newline at end of file diff --git a/etc/yearlies/2024.md b/etc/yearlies/2024.md new file mode 100644 index 00000000000..0b660f25adc --- /dev/null +++ b/etc/yearlies/2024.md @@ -0,0 +1,199 @@ +##### The year in numbers + +And 365 days later as of 2024-12-31, we are counting **178,156 SLOC, up by 37,151**, which is 108% *of the year before* (➡*OTYB*) in **15,271 commits up by 2,269** and 75%OTYB. There are **78 crates (up by 16)** and 2 binaries, with `ein` and `gix` as part of `gitoxide`. There are **151 unique authors (up by 46 and 96%OTYB)**. This means ~102 lines per day in ~6 commits each day. On GitHub there are **9279 stars (up by 2,013 which is 96%OTYB)** for ~5.5 stars per day. + +The tool invocation `ein tool estimate-hours` now rates the project cost at **10629 hours (up by 1893 which is 99%OTYB) or ~1329 x 8 hour working days**, for an average working time of **5.18 hours in the past 365 days**. + +My timetracker reveals that I **spent 892h on open source work** (which is 57%OTYB) which is (still) dominated by `gitoxide` and which is supported [_via GitHub sponsors_](https://github.com/sponsors/Byron) at 619h. **1020h were for commercial work and consulting** (which is 217%OTYB). The **total of 1912 hours worked** boils down to **5.2 hours of work per day (36.8h per week)**, which is 94%OTYB. + +My open-source work is still financially sustainable even without income through commercial work, which is something I am most grateful for. + +Thus far, **I have spent the last 1719 days to getting `gitoxide` off the ground**, and it's still quite far from even reaching parity with `git2` despite making great strides. Even though feature-wise it's getting closer, it's still unclear how to get everything to stability while also making the API easy-to-use, yet powerful enough to squeeze out every last bit of performance. + +### Plans and reality + +When looking at the "What was planned for 2023" section in the [last year's retrospective](https://github.com/GitoxideLabs/gitoxide/discussions/1223) it's astonishing that I seemed to have accomplished none of the items left or planned, with the exception that `gix status` is nearly ready at the time of this writing. + +Then again, none of the other unfulfilled items on the plan were actually attempted. + +This brings us to the highlights of the features *actually* completed in 2024, as picked from the previous monthly reports, in order of (utterly subjective) importance. *And for brevity, I skip over the large amount of smaller improvements and fixes that happened in the course of the year.* + +#### Blob and tree merge + +In what felt like more than two months of work a complete implementation of a `merge-ORT` style tree-merge algorithm was implemented, along with a complete and fully-fuzzed blob-merge. It seems to be a bit faster than `git merge` in many (but not all) cases and a lot faster than the tree merge in `git2`, while offering additional features to help auto-resolve conflicts while still 'communicating' them. + +This is particularly useful if one were to produce trees that make sense from *our* point of view *automatically* while knowing that the auto-resolution still has to be replaced by a user-controlled one *at some point in time*, a convenience implemented in [GitButler](https://gitbutler.com). They were also the sponsor for the entire feature so it could be geared to work particularly well for such a modern developer tool, speeding up their merges by up to 3x. + +A smaller but no less important feature that powers all of that is the new tree-editor. It supports sparse immediate edits to later write out only the trees that changed for maximum efficiency. + +#### `gix clean` with precious files + +Definitely my personal favorite and a tool I use often if `gix clean` with its awareness of [precious files](https://github.com/GitoxideLabs/gitoxide/discussions/1308). These files are not to be tracked, but also not disposable, and a great way to keep your editor-configuration safe. + +It's powered by the new `gix-dirwalk` crate which helps to classify entire directories, and is the basis for `gix status` and future `gix add` as well. + +#### `gix status` (*nearly there*) + +It has been such a long time in the making, and despite best attempts (i.e. my really trying a week before the year's end), it's still not quite there. But what's there is very promising as it seems to be 1.85 faster than Git on the WebKit repository already. Git is very optimised, but it's not as parallel as it could be which is where `gitoxide` has its major gains. The directory walk to find untracked files and the index-refresh are run in parallel, something that ultimately is faster even though Git would otherwise be a bit faster if run sequentially. + +As a special feature, `gitoxide` implements the `status` query as iterator which *moves the work out of the consuming thread*, something that will further accelerate real-world applications without any added complexity on their side. + +Of course, the complexity has to go somewhere and `status` as it's implemented now is a multi-layered monster of what seems like essential complexity. + +#### A very first `gix blame` + +Thanks to [Christoph Rüßler](https://github.com/cruessler) and his tireless work (*as well as super-human patience with me*) we now have a very first working version of `gix blame`. It works! + +Early next year we would expect its performance to become comparable to Git as well, which has many more optimizations that really make a difference. With a little luck it has a good chance to be faster as well. + +It's well worth mentioning that I think that `gix blame` has to the potential to become the fastest blame implementation available, while being the most suitable for [user interfaces](https://github.com/extrawurst/gitui) as well. + +#### Ephemeral objects and API improvements + +Often it's useful to just *try* something without leaving any trace of it. This could, for example, be answering if something would merge cleanly or not. +Now it's possible to turn on [in-memory objects](https://docs.rs/gix/0.69.1/gix/struct.Repository.html#method.with_object_memory) so all new objects are kept in memory instead of ending up as garbage on disk. + +On top of that, various convenience methods have been added to make the API around these parts as easy to use as they are in `git2`. + +#### A great year for security + +Thanks to the generous sponsorship of [Radicle](https://radicle.xyz) via [Drips](https://www.drips.network) the fabulous [Eliah Kagan](https://github.com/EliahKagan) could join and make sure that [exploitable vulnerabilities](https://github.com/GitoxideLabs/gitoxide/security/advisories) don't stay hidden for long! + +I sure learned a lot while working with him even though I still wouldn't claim to be able to write perfectly secure code, despite using only safe Rust. It's very tricky, and truly is an independent skill to develop. + +#### Release Notifications + +It was also him who added countless other improvements, among which also is *release notifications*. Just subscribe to [this discussion](https://github.com/GitoxideLabs/gitoxide/discussions/1693) to be informed only about `gitoxide` releases, something that typically happens once a month. + +### A word of Gratitude + +By now I am able to sustain myself and my family while following my calling, and for that I am incredibly grateful - I simply couldn't imagine a better use of my (life)time. Doing so would not be possible without the generosity of my sponsors and the trust of my clients: thank you, thank you *very much*! + +Another big thanks goes to the 46 new contributors whose fixes and improvements helped `gitoxide` get closer to the best possible version of itself. + +Some shoutouts shall follow. + +#### At your service, GitButler! + +When GitButler got in touch, judging by my initial response, I must have *felt* that this could be a life-changing event. And even that might have been an understatement. + +After all it's not just helping to make [GitButler](https://gitbutler.com) the best Git client and developer tool. It's also feeling like being a part of the global Git community, with a massive opportunity [to meet all the people](https://merge.berlin), just before getting [to speak on GitMerge](https://www.youtube.com/watch?v=r1LwDYtghPM) about `gitoxide`. + +And if this was just the warmup, I can't even imagine how 2025 is going to be. Let's find out! + +#### Thank you, Josh! + +[Josh Triplett](https://joshtriplett.org/), back in May 2021 became my first sponsor and *patron*, which did no less than change my life to be able to follow my calling. `gitoxide`, me and my family wouldn't be what they are today without him, and I am deeply grateful for that. Nothing ever has to change about this sentence. + +As 2024 turned out to be great in more ways than one, I am glad to say that [`buildit`](http://buildit.dev) came along well despite not yet being available to the public. But it's getting there, we will make sure of it 🙌. + +#### Thanks, Radicle! + +[Radworks](https://radworks.org) is dedicated to cultivate internet freedom. They created [a peer-to-peer network](https://radicle.xyz) for code collaboration based on Git, which is the reason we touched base back in 2021. + +In September 2023 through 2024 `gitoxide` became an early benefactor of [Drips](https://www.drips.network), which alone would have been enough to secure its future. Thank you! + +I am unlikely to be able to thank them enough, but will try by making `git2` a dependency they won't need anymore. + +#### Thanks, `git2`! + +Speaking of `git2`, it's a lighthouse project to me which shows how to do `libgit2` bindings right. It definitely sets the standard for convenient and easy-to-use APIs, it's not easy to match, and definitely something to aspire to. + +Further, they split the majority of their donations on [Drips](https://www.drips.network) with `gitoxide`, which made bringing on [Eliah Kagan](https://github.com/EliahKagan) to greatly enhance its security posture possible. + +I will do my best to do well by you and truly make `gitoxide` the project that makes it the go-to Git crate in the Rust ecosystem. + +#### Thank you, Cargo team, for bearing with me! + +It's taking me years to finish the integration work and implement all features needed to fully replace `git2` in `cargo`, and yet the `cargo` team stays onboard with this work! + +Thanks so much, but… `gix status` is now unstoppably coming, and soon I will get to continue the integration. +2025 - the year it continues! + +#### Thanks Everyone + +It’s very likely that I failed to call *you* out for no other reason than swiss-cheese like memory, so let me thank you for the net-positive interactions we undoubtedly had. + +Let’s do that again in 2025 :)! + +---- + +🎉🎉🎉 Thanks for reading, let's make 2025 a great year for everyone :)! 🎉🎉🎉 + +---- + +### Q&A + +These really were questions I asked myself when writing the report, and I thought they might be interesting to share. + +#### Why were there fewer commits than in the last year, despite more code overall? + +The sole reason for this certainly os [StackedGit](https://stacked-git.github.io), a tool that facilitates maintaining patch-queues. That way, commits get rewritten over time to remain a logical unit with a clear commit message of what was done, instead of being a sequence of commits that merely document changes over time. + +#### Why is the overall time worked down by 133h? + +This amount of time seems to match the time I spend on 'special events' related to care-taking. As people get older, this will probably not get better. It's worth noting that these hours are focus-time, without breaks, so I'd think overall the pace of work is the same. Of course, I am always trying to do more, but it's probably not going to happen. + +
Data + +##### State + +```shell +❯ git rev-parse @ +6ed9976abaa3915b50efa46c46b195f3a1fc4ff7 +``` + +##### Commits + +```shell +❯ git log --graph --pretty="%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%ar) %C(bold blue)<%an>%Creset" | wc -l +15271 +``` + +##### Linecount + +``` +=============================================================================== + Language Files Lines Code Comments Blanks +=============================================================================== + JSON 1 7 7 0 0 + Makefile 1 158 112 10 36 + Shell 162 13825 11481 589 1755 + SVG 1 21 21 0 0 + Plain Text 34 686 0 548 138 + TOML 95 4377 3195 454 728 +------------------------------------------------------------------------------- + HTML 1 327 324 0 3 + |- CSS 1 12 2 10 0 + |- JavaScript 1 1 1 0 0 + (Total) 340 327 10 3 +------------------------------------------------------------------------------- + Markdown 136 85644 0 63866 21778 + |- Dockerfile 1 4 3 0 1 + |- Python 1 10 6 2 2 + |- Rust 2 64 61 0 3 + |- Shell 2 8 7 1 0 + (Total) 85730 77 63869 21784 +------------------------------------------------------------------------------- + Rust 1346 198154 178156 1964 18034 + |- Markdown 841 18988 2 16172 2814 + (Total) 217142 178158 18136 20848 +=============================================================================== + Total 1777 303199 193296 67431 42472 +=============================================================================== +``` + +##### Authors + +```shell +❯ ein t h + 08:39:54 traverse commit graph done 13.5K commits in 0.10s (141.9K commits/s) + 08:39:54 estimate-hours Extracted and organized data from 13540 commits in 55.75µs (242869968 commits/s) +total hours: 10629.23 +total 8h days: 1328.65 +total commits = 13540 +total authors: 151 +total unique authors: 146 (3.31% duplication) +``` + +
\ No newline at end of file