Repository navigation
Crash when selectively staging last change #5078
Description
Describe the bug
There's an off-by-one when you incrementally stage the last hunk of a file. maybe only if it's the last file in the list? anyway it happens to me constantly and I just pulled the latest version to try to fix, but it's still there.
To Reproduce
Steps to reproduce the behavior:
have multiple files changed, filter by only unstaged, start staging hunks. i've seen this happen a lot, but not every time?
Expected behavior
no crash
Screenshots
panic: runtime error: index out of range [1] with length 0
goroutine 452 [running]:
github.com/jesseduffield/lazygit/pkg/commands/patch.headerInfo({0x40009220fb?, 0x4bc?})
github.com/jesseduffield/lazygit/pkg/commands/patch/parse.go:47 +0xd0
github.com/jesseduffield/lazygit/pkg/commands/patch.Parse({0x4000922000?, 0x4bd?})
github.com/jesseduffield/lazygit/pkg/commands/patch/parse.go:22 +0x2fc
github.com/jesseduffield/lazygit/pkg/gui/patch_exploring.NewState({0x4000922000, 0x4bd}, 0xffffffffffffffff, 0x40000f98c8, 0x40002ca5b0, 0x1)
github.com/jesseduffield/lazygit/pkg/gui/patch_exploring/state.go:56 +0x94
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*StagingHelper).RefreshStagingPanel(0x400021c778, {{0x0?, 0x4000bba658?}, 0x10c16c?})
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers/staging_helper.go:67 +0x220
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).Refresh.func2.13()
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers/refresh_helper.go:177 +0x3c
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).Refresh.func2.1.2()
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers/refresh_helper.go:114 +0x80
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).Refresh.func2.1.gowrap1.Safe.1()
github.com/jesseduffield/lazygit/pkg/utils/utils.go:69 +0x24
github.com/jesseduffield/lazygit/pkg/utils.SafeWithError(0x1e?)
github.com/jesseduffield/lazygit/pkg/utils/utils.go:80 +0x5c
github.com/jesseduffield/lazygit/pkg/utils.Safe(...)
github.com/jesseduffield/lazygit/pkg/utils/utils.go:69
created by github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers.(*RefreshHelper).Refresh.func2.1 in goroutine 1
github.com/jesseduffield/lazygit/pkg/gui/controllers/helpers/refresh_helper.go:111 +0x110
Version info:
╰─❯ lg --version
commit=, build date=, build source=nix, version=0.56.0, os=linux, arch=arm64, git version=2.51.2
╰─❯ git --version
git version 2.51.2
Additional context
Add any other context about the problem here.
Note
Please try updating to the latest version or manually building the latest master to see if the issue still occurs.
Activity
stefanhaller commentedon Dec 1, 2025
I briefly tried to reproduce this, but couldn't so far; I did see some misbehavior where junk gets staged, so this seems related, but it didn't crash on me so far. Note, I only saw misbehavior in files that don't end with a newline, and then changing the last line and trying to stage that.
So if you can come up with a more concrete recipe for making it crash, that would be helpful (like exact content of the file, and the change that you are trying to stage).
codingismy11to7 commentedon Dec 8, 2025
ah yeah as i did it more and more i narrowed down on exactly what caused it. I figured the stack trace would be good enough even without an exact repo though. anyway, i've since completely forgotten how to reproduce this (it was a long weekend), so once i get back into the groove this week and figure it out again i'll come and post.
i do remember that it didn't turn out to have to be the last file in the list. it was while doing a rebase. as in i was rebasing ~60 commits that were all conflicted. so every time i finished a commit and went to the next, lazygit would filter my files to conflicted only, and i'd hit Enter on one (usually the first or last) to start selectively staging it. so i guess this is different - my bug was saying selective staging, but really this is selective conflict resolution. sorry, been a bit frazzled. anyway, once i get to teh last chunk of the conflicted file and pick one, that's when lg would panic. i believe it successfully saved the file first, though
again, that's my memory, when i get an exact repro i'll post
10kartik commentedon Nov 1, 2026
Had a look at the stack trace.
Parsetreats every line starting with@@as a hunk header, buthunkHeaderRegexponly matches@@ -a,b +c,d @@. For an unmerged filegit diffprints a combined diff with headers like@@@ -1,3 -1,3 +1,3 @@@, soFindStringSubmatchreturns nil andheaderInfopanics onmatch[1]. Passing such a diff topatch.Parsegives exactlyindex out of range [1] with length 0.I couldn't get there by clicking through the UI though (Enter on a
UUfile without markers does nothing, and it gets auto-staged anyway). My guess is the staging view was already open on a file when a rebase step made it conflicted again, which would fit with this happening during a long rebase.