Worktree.Status() always fail

[kyoh86]

It always return invalid checksum for any repository.

$ go version
go version go1.16.3 linux/amd64

[JanDeDobbeleer]

@kyoh86 same for me. Falls back to this check, which, if I remove it, resolves the issue and things actually work. So I have no idea why this check is in there.

[c-carpenter]

I am running into the same issue. Oddly others on my team are able to run the code in question, but I am not.

[c-carpenter]

In my case the issue was that I had enabled a new git feature: FSMonitor. go-git does not support the header for this feature yet and thus was causing it to barf.

[c-carpenter]

After a night of sleep, the probable best direction to take this issue is to improve the error handling on the plumbing/format/index/decoder.go. It currently assumes that an error means it has reached EOF and thus is done. But there are many possible error cases that can happen within the loop. Better handling of the errors that happen within the for loop will result in better understanding of what is happening for the users.

[maticrivo]

I'm facing the same issue even with FSMonitor turned off.. is there a fix for this?

[kyoh86]

@mcuadros how about this?

[maticrivo]

any news on having a fix/workaround for this?

[zkmoney]

I ran into this issue as well, and ended up building from source and mucking around a bit to try and figure out what was going on. Not sure if it's helpful for anyone else, but my issue was that I had in my .gitconfig

core.untrackedCache = true

and that was causing a git index header of UNTR to be in the mix, and was throwing off the Decoder.readExtension method, as the package didn't know how to handle that. (I don't really know much about all of these internals, and got pretty lucky I think, so unfortunately don't have much context for what any of this means).

Anyway, I remove the setting from my .gitconfig and it worked great.

[florianrusch]

I created for testing purposes a small repo locally with only one commit in it. If I now try to execute worktree.Status() on this repo it's throwing the same error.

I already checked, the described workarounds/fixes from this Issue, but none of them worked so far:

• I'm not using the FSMonitor at all
• untrackedCache was set to true, but setting this to false doesn't helped

I also tested to comment out most of my .gitconfig stuff - still the same result 😕

[pjbgf]

@florianrusch would you be able to share a concise steps to reproduce? Does this happen on a specific public repository?

[florianrusch]

Okay, I have it reproducible 💪 and I think I found my problem too. So first I will describe my problem and solution and then below you will find my setup/steps to reproduce it.

My problem & solution

• When I created the repo, I had set core.untrackedCache = true in my global .gitconfig. As described by @zkmoney, this triggers the error => error: invalid checksum
• Only changing core.untrackedCache to false in my .gitconfig did not work and I still have the same error
• BUT: If I run a git command (e.g. git status) in the repo after changing core.untrackedCache, the error is gone 🥳

So I guess that something must be executed that changes/updates the git index (maybe the term index is wrong - I don't have deep insight into how git works). Just changing core.untrackedCache without doing anything in the repo itself did nothing.

---

Steps to reproduce

Have the following in you .gitconfig

[core]
	untrackedCache = true

Do the following steps to create the repo:

git init
touch README.md
git add README.md
git commit -m "INIT"
git status

And this is my go program. I received the error from the worktree.Status() method.

path := "/path/to/my/repo"

r, err := g.PlainOpen(path)
if err != nil {
	return err
}

worktree, err := r.Worktree()
if err != nil {
	return err
}

status, err := worktree.Status()
if err != nil {
	return err
}

[github-actions[bot]]

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!

[kyoh86]

it's still alive.

[pjbgf]

A fix for this has been proposed on #1066. It would be great if anyone still experiencing it could confirm that it fixes the issue for them.