erases all uncommitted git changes on compilation failure

[dablenparty]

Affected Version

yay v13.0.1 - libalpm v16.0.1

Describe the bug

yay erased every single uncommitted change in my git repo, not just the changes in the PKGBUILD, when it failed to compile. If it had done this after a successful install, I'd at least understand.

This also means I cannot clean build local PKGBUILDs at all because that requires generating a .SRCINFO file, but since that's an uncommitted file, it gets immediately erased before yay tries to read it and then it complains "no .SRCINFO found!".

I reported this years ago when this first happened; I moved to paru after but that's been dead for nearly 6 months now so I tried yay again... I won't be using yay anymore.

Reproduction Steps

1. have a custom PKGBUILD in a git repo
2. make changes anywhere in the repo without committing them
3. try to compile & fail
4. observe uncommitted changes are now gone

Expected behavior

Does not erase changes after a failed compilation.

I am NOT running this again and erasing my changes just to capture the output.

Config:

{
	"aururl": "https://aur.archlinux.org",
	"aurrpcurl": "https://aur.archlinux.org/rpc?",
	"buildDir": "/home/hunterd/.cache/yay",
	"editor": "",
	"editorflags": "",
	"makepkgbin": "makepkg",
	"makepkgconf": "",
	"pacmanbin": "pacman",
	"pacmanconf": "/etc/pacman.conf",
	"redownload": "no",
	"answerclean": "",
	"answerdiff": "",
	"answeredit": "",
	"answerupgrade": "",
	"gitbin": "git",
	"gpgbin": "gpg",
	"gpgflags": "",
	"mflags": "",
	"sortby": "",
	"searchby": "name-desc",
	"gitflags": "",
	"removemake": "ask",
	"sudobin": "sudo",
	"sudoflags": "",
	"version": "13.0.1",
	"requestsplitn": 150,
	"completionrefreshtime": 7,
	"maxconcurrentdownloads": 1,
	"bottomup": true,
	"sudoloop": false,
	"devel": true,
	"cleanAfter": false,
	"keepSrc": false,
	"provides": true,
	"pgpfetch": true,
	"cleanmenu": true,
	"diffmenu": true,
	"editmenu": false,
	"combinedupgrade": true,
	"useask": false,
	"batchinstall": false,
	"singlelineresults": false,
	"separatesources": true,
	"debug": false,
	"rpc": true,
	"doubleconfirm": true,
	"rebuild": "no"
}

[github-actions]

🤖 This is an automated response from Repo Assist.

The current worktree cleanup paths use destructive Git commands: the clean menu runs git reset --hard origin/HEAD followed by git clean -fdx, and the post-install CleanAfter hook runs git reset --hard HEAD followed by git clean -fx. Both reset tracked changes and remove untracked files, including a generated .SRCINFO. That matches the reported data-loss symptom if either cleanup path runs after the failed build.

A safe fix should preserve user changes by avoiding reset/clean on source directories containing local modifications, or by building in an isolated checkout/worktree; changing these commands globally could weaken the existing clean-build behavior. The issue would benefit from a reproduction that identifies whether CleanMenu or CleanAfter is enabled when the failure occurs.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@1c6668b751c51af8571f01204ceffb19362e0f66