`gitui` uses `gitoxide`

[Byron]

Required Features

• fetch with detailed progress
• blame
• merge_analysis
• merge
• reference_to_annotated_commit
• rebase (with abort and continuation)
• ref listing and creation (branches, tags)
• create a new commit (index to tree, then commit; amend)
• read objects in all kinds of ways
• recurse trees
• diff trees with detailed delta information
• revparse
• access git configuration
• use credential helpers
• diff tree to index
• diff index to workdir
• file diffs with hunk-API (would be using imara diff directly at present)
• traverse commit graph
• push with progress
• list remotes
• reset worktree conveniently, possibly with pathspecs
• reset portions of index, conveniently with pathspecs
• repository paths
• stash
• repository state
• git status
• list submodules and submodule info
• fetch submodule conveniently, i.e. submodule.update()
• rename branch (while updating its references in .git/config, needs high-level branch rename and writing git configuration
• create revert commit

https://github.com/extrawurst/gitui

[mati865]

There is a typo in the title: s/gittui/gitui/ 😉

[Byron]

Fixed, thanks!

[cruessler]

@Byron I just found this issue, and I would like to start contributing to gitoxide if possible. :-) I already found the project board, but was quite overwhelmed initially. Would you be able to point me to an issue that ideally combines these 2 goals: 1. is in service to the areas listed in this issue’s description, 2. is self-contained and not time-critical, so can tolerate if I have to interrupt working on it for a couple of days.

Sorry in advance if this is not the best conversation channel, in which case I’d ask you to please refer me to a better one. :-)

[Byron]

Thanks so much for offering, I think this is a great place to talk!

During The Merge @extrawurst and I talked about blame a little bit and concluded that this could be implemented much faster and more interactive than it's implemented now. That way, it should be very suitable for for gitui to the point where it could be a unique-selling-point.

It would fulfil your criteria and could be placed into its very own plumbing crate, isolating it neatly while making you acquainted with the lower-level building blocks of this project. Lower-level doesn't mean it's difficult, it probably only means that it's simple, with fancy stuff and integrations coming in with higher-levels. This really helps with focus, too.

It's also not an easy task, but I'd be there to help along the way once a draft PR is up.

Here are the features I think it would have to fulfil:

• it is interruptible and provides progress
• the search for changed hunks is done in parallel, i.e. multi-threaded diffing
• hunk information (i.e. which lines were changed by which commit) is communicated in real-time to the caller
• (and the reason for this to exist): make it resumable so one can skip-over commits without starting from the beginning

From a gitui perspective, one would be able ti display the lines of a file on the right while leaving some margin on the left (for example) for commit information. As commits are found these are displayed. Progress is shown to indicate which percentage of the file is already equipped with commit information. If the user goes away early, the blame computation is aborted instantly. Once the blame is done, the user can indicate which commits they don't want to see, and the blame can be resumed to skip over those and keep searching. I'd make it so that these commits to skip over can be provided at the start of a blame as well so users don't have to specify these over and over - which project doesn't have the 'moved files' or 'changed indentation' commits that are generally not interesting?
Bonus points if commits to skip over can be provided while the blame is being computed - that would require a channel into the algorithm.

Please note that all building blocks you'd need area already available, like:

• commit traversal
• tree-to-tree diffs with rename tracking, and proper processing of what is being diffed, like worktree and diff filters
• blob diffs - only this can easily be parallelised and should be parallelised.

That's my brain dump about the feature, and is what I'd do if I wanted to bring it into gitui, probably you have a ton of ideas as well that you are welcome to try out and experiment with.

I'd also offer a 1h zoom session to get you started, and you can send me an email if that interest you. Fun fact: this is something I can do because I talked to @extrawurst on The Merge, it's so useful to meet in person from time to time :).

[extrawurst]

@Byron thanks for the brain dump, thats exactly what I discussed with @cruessler (also in person the day after merge - can only agree how valuable this is)!

We agreed that ideally we lay out the interface we would want for this by working backwards and making the current blame (using libgit2) in gitui async first, this way we have a pretty good idea on how this needs to look from a user perspective of this feature when then migrating it over to gix