eza-community
feat: Support for sha256 git repositories
Summary
Add support for git repositories using the sha256 object format.
Currently, when using a sha256 git repo, the branch and status display functions do not work.
Steps to trigger the problem:
1. Create sha1 git repo:
- Create folder for git repo with sha1:
mkdir test-sha1. - Enter to directory:
cd test-sha1. - Create repository with sha1 object format:
git init --object-format sha1. - Create file:
echo "test" > file.txt. - Stage file:
git add file.txt. - Commit file:
git commit -m "Add file.txt". - Return:
cd ...
2. Create sha256 git repo:
- Create folder for git repo with sha256:
mkdir test-sha256. - Enter to directory:
cd test-sha256. - Create repository with sha256 object format:
git init --object-format sha256. - Create file:
echo "test" > file.txt. - Stage file:
git add file.txt. - Commit file:
git commit -m "Add file.txt". - Return:
cd ...
3. Check the result:
- Run eza:
eza --long --git-repos. - Catch the wrong behavior.
Actual Behavior:
The functions related to displaying the branch name and repository status are not working.
Example (from my system):
... + main book-rust-in-action
... | main configs
... - - cryptography
... - - docker-compose-files
In the above example, I have left only the directories containing the git repositories. As you can see, some of them use sha1, while others use sha256.
Repositories using sha256 are displayed as simple directories without git repositories.
Expected Behavior:
The functions related to displaying the branch name and repository status are working.
Eza version and system specs:
- Eza: v0.20.23 [+git]
- OS: Archlinux 6.13.5-zen1-1-zen
This would indeed be super cool, if anyone wants to work on support consider it endorsed!
First issue will be libgit2 seemingly (allegedly?) not supporting it https://github.com/libgit2/libgit2/discussions/5840#discussioncomment-10845200
Moving from libgit2 would likely be a much larger scope issue (not that it would be unwelcome, if there is rust libraries with acceptable maturity and feature parity).
If we were to move to gitoxide, we should move entirely from libgit2, and that's a major task, so it may be worth holding back on it a bit. I'm also not sure gitoxide has all the features we would need