`tix` MVP

[Byron]

A minimal replacement for how I use tig, with an architecture that…

• never block the main thread
• is testable
• allows for replacement of the actual UI, allowing application logic to be reused in the browser or with Tauri, for example

Scope

• display a single branch only, as a flat list
• display refs
• an easy way to copy the hash of the selected commit
• display the total amount of commits
• jump to the beginning of history and the latest commit
• cancel long-running processes
• display progress of long-running processes

Performance

• display history instantly on the linux kernel
• use way less than 1.5GB of memory after jumping to the beginning of history
• see how close it gets to /usr/bin/time -lp zsh -i -c 'glo > /dev/null' (about 8s, 280MB heap size, 1GB incl. virtual)

Implementation

• The git-tix crate is a library for a binary
• gitoxide provides the tix binary using the git-tix crate as implementation

[kalkin]

Just stumbled upon this issue. Have a look at this https://github.com/kalkin/git-log-viewer My next step would be replace the git backend of gitoxide.

[Byron]

@kalkin Now that's a nice coincidence and I am excited to see git-log-viewer grow into a tool I could use way before tix is available!

And with worktree support being fully implemented, something I currently work on, you should already have most if not all of the features you'd need for the implementation. If something is missing, you could collect it in an issue so I can use it to help with prioritizing what's next.

All the best!

[kalkin]

I just ported some other tool of mine to using gitoxide. I have not found any way to parse revision and ranges like specified in gitrevisions(7). Am I right that this functionality is missing?

I have a partial implementation which currently parses things like HEAD~1^2. If you are interested I could complete the implementation and do a PR. Just tell me in which module it should go.

[Byron]

Am I right that this functionality is missing?

Indeed, revspec parsing and pathspec parsing are currently missing, but @SidneyDouw and were planning to work on it soon.

If you are interested I could complete the implementation and do a PR. Just tell me in which module it should go.

It would be great to be part of the development in case you want to open a draft PR sooner than later. Parsing would go into the git-revision crate and have the following requirements.

• parse plain bytes (or &BStr), not &str
• call functions to signal which item was parsed, that is it doesn't parse into a data structure

This design makes it possible to validate by making each callback a no-op and to produce the final object id step by step otherwise if a Repository instance is providing the callbacks.

If your design differs and you'd understandably like to keep it that way, I'd still appreciate if a link to it could be dropped here as the test suite could give gitoxide a head-start for its own implementation.

[kalkin]

After a few more experiments the following things are currently blockers for porting glv to gitoxide.

1. Range and revision parsing
2. Robust merge-base implementation with support for commit-graph. This is also needed for parsing ranges to a list/iterator over Id.
3. Forkpoint calculation, needs 2. Can be implemented inside glv but i think this should be a part of gitoxide.

[kalkin]

• parse plain bytes (or &BStr), not &str

If we are speaking about this, why does gitoxide even use BString instead of just taking AsRef<[u8]>? As far as I understand ist BString just a byte stream without any encoding validation. Usage of AsRef<[u8]> would allow to pass a normal string everywhere without casting it to BString.

[Byron]

Let's use https://github.com/Byron/gitoxide/issues/411 to track what it needs to use gitoxide in glv. I took the liberty of arranging various issues you created so that I can handle them more efficiently.

The goal would be to put you into a position where rev-spec parsing can be implemented in all layers.

If we are speaking about this, why does gitoxide even use BString instead of just taking AsRef<[u8]>?

It's more convenient to work with. One of the killer features is its ability to Debug print as text, but getting standard and efficient str-like capabilities on a bunch of bytes is very helpful as well.