-
-
Notifications
You must be signed in to change notification settings - Fork 329
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Showing
1 changed file
with
142 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,142 @@ | ||
| ### 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. | ||
|
|
||
| ### 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. | ||
|
|
||
| <details><summary>Data</summary> | ||
|
|
||
| ##### 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) | ||
| ``` | ||
|
|
||
| </details> |