Gitu crashes when a submodule is moved or deleted
Open
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 2.9k
- Forks
- 164
- PR merge metrics
- No merged PRs in 30d
Description
After running:
git rm <path/to/submodule>
gitu's main thread panicked with the following information:
thread 'main' panicked at src\git\mod.rs:157:64:
called `Result::unwrap()` on an `Err` value: Expected "<eof>" at byte 318
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Similarly, if a repository has a moved submodule, gitu fails to start. The stacktrace is badly formatted with spurious whitespace, so I've omitted it.
> git status
On branch work/modernize
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: .gitmodules
renamed: <old/path> -> <new/path>
[...]
> gitu --print
gitu --print
thread 'main' panicked at src\git\mod.rs:157:64: called `Result::unwrap()` on an `Err` value: Expected "<eof>" at byte 240
stack backtrace:
0: 0x7ff70cd966d2 - git_odb_object_data
...
I will try to produce a reproduction repo later when I've got the time.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at src/git/mod.rs:157 and reproduce the failure with git rm on a submodule and with a moved submodule. Check that gitu and gitu --print start without panicking and correctly handle the resulting repository state.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100