Devolutions / Devolutions/UniGetUI
[IMPROVEMENT] Improve Git upgrade failure handling when Git processes are running
- Dominant language
- C#
- Stars
- 26.1k
- Forks
- 924
- Avg merge
- 15h 52m
- Merged PRs (30d)
- 52
Description
### Please confirm these before moving forward.
- [x] I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
- [x] This improvement refers to an existing feature. If you want to suggest a new feature, please use [this template](https://github.com/Devolutions/UniGetUI/issues/new?labels=new-feature&projects=&template=feature-request.yml&title=%5BFEATURE+REQUEST%5D+%28Enter+your+description+here%29).
- [x] This improvement is not a bug. If you want to report a bug, please use [this template](https://github.com/Devolutions/UniGetUI/issues/new?labels=bug&projects=&template=bug-issue.yml&title=%5BBUG%5D+%28Enter+your+description+here%29).
### Describe the improvement
Improve error reporting when a package installer fails because running processes are blocking the installation (e.g. Git).
## Current behavior
When updating Git through UniGetUI using WinGet, the installation may fail with a generic error.
In my case, UniGetUI reported only that the update had failed.
After inspecting the installer log generated by the package installer, the actual reason was:
```text
The following process(es) use Git for Windows:
Git for Windows (PID ...)
...
Please terminate those processes and retry.
```
The installer aborts because it is executed in silent mode (`/VERYSILENT`), so it cannot prompt the user to close the running processes.
## Expected behavior
**If possible**, it would be helpful if UniGetUI could surface the underlying installer error whenever it provides a more specific reason than the generic failure reported by WinGet.
For example, in this case, UniGetUI could display a message such as:
> Git is currently being used by one or more running processes. Please close the applications using Git (or terminate the listed processes) and try the update again.
Optionally, UniGetUI could offer a **Retry** button after the user has closed the blocking processes.
### Describe how this improvement could help users
Without checking the installer log, it is not obvious why the update failed. A clearer and more actionable error message would save users from having to manually inspect log files for a very common scenario.
This is not a WinGet or Git installer bug—only a suggestion to improve the user experience in UniGetUI by surfacing the actual installer failure reason whenever possible.
Contributor guide
Research direction
Start by tracing UniGetUI's WinGet installation failure handling and how installer logs are surfaced when a package update fails. Check whether the underlying process-blocking reason can be exposed and define done as showing an actionable message, with retry only if the existing update flow supports it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, git
- Domain
- desktop, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100