Open Byron opened 2 years ago
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.
@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!
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.
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.
&BStr
), not &str
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.
After a few more experiments the following things are currently blockers for porting glv to gitoxide.
Id
.glv
but i think
this should be a part of gitoxide
.
- 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.
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.
A minimal replacement for how I use
tig
, with an architecture that…Scope
Performance
/usr/bin/time -lp zsh -i -c 'glo > /dev/null'
(about 8s, 280MB heap size, 1GB incl. virtual)Implementation
git-tix
crate is a library for a binarygitoxide
provides thetix
binary using thegit-tix
crate as implementation