Description of problem: The worktree gets into a inconsistent state after a merge with conflicts. Version-Release number of selected component (if applicable): git-2.14.3-3.fc27.x86_64 How reproducible: Sometimes. Always once the index file is corrupted. Steps to Reproduce: 1. git status Actual results: fatal: multiple stage entries for merged file 'sources' Expected results: The usual git status output. Additional info: This happened after a merge with conflicts. After the conflict, I called the equivalent of “fedpkg new-sources”, which performs a “git add” for .gitignore an, I think, and edits the “sources file”.
Hmm, I wonder if fedpkg (or really GitPython which it uses to manipulate the index) is corrupting the index here. AFAICT, `fedpkg new-sources` doesn't fork out to `git add` but instead GitPython writes the index itself. The check for 'multiple stage entries' was added in git-2.2.0, 15999d0be8 ("read_index_from(): catch out of order entries when reading an index file", 2014-08-29). I suspect you found this, but in case not or for others who stumble onto this, I believe the way to fix things once the index is corrupted is to remove it and rewrite it, e.g.: rm -f .git/index && git reset If it's possible to trigger the conflicted merge state and subsequent corruption easily enough, it might be useful to test a little to determine if this is fedpkg/GitPython. Ideally, if you get to the conflicted merge, copy the repo and in one copy run `fedpkg new-sources` and in the other manually make the changes to the 'sources' file and run `git add sources`. I'll try to poke around a little and see if I can reproduce this with GitPython directly.
I tried to come up with a way to reproduce this and didn't succeed. If anyone can come up with a way to reproduce this without using fedpkg or any other tools which might write to the index outside of git, it would be useful. Otherwise I don't know if there's much we can do about it in git. The git error was added to report such index file corruption. The thread where this fatal message originated is: https://public-inbox.org/git/1407857491-16633-1-git-send-email-jsorianopastor@gmail.com/ Output from `git ls-files -u` (and/or -s) in a corrupted repo may be useful in helping to see what sort of corruption is happening. Maybe that will make it easier to reproduce and get reassigned and fixed in the proper component.
I found that this issue was filed upstream with rpkg: https://pagure.io/rpkg/issue/222 It may get resolved in rpkg via some additional checks in new-sources, though it looks like there could be an underlying bug in GitPython/gitdb which causes the problem.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.