| Summary: | devel/gitqlient: .git/index.lock exists after closing the application | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Graham Perrin <grahamperrin> |
| Component: | Individual Port(s) | Assignee: | Adriaan de Groot <adridg> |
| Status: | Closed Unable to Reproduce | ||
| Severity: | Affects Only Me | CC: | freebsd, grahamperrin |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(adridg) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Graham Perrin
2023-03-25 19:12:37 UTC
(In reply to Graham Perrin from comment #0) yes please do Can't reproduce, though (with an arbitrary local git repo, although all I do is start the application, open a repo, and then close the application): can you give me some steps to reproduce? I can reproduce existence of the remnant, however I don't yet have reproducible steps. It will take some time for me to make things reproducible, shall we close this bug in the meantime? With an assumption that it might be fixable upstream. It's worth filing upstream (nothing open there related to stray lock files, though). The thing I can imagine is this: - some git operation is running - gitqlient exits - .. and kills the git process that is doing the work (or rudely interrupts the thread doing the work, I don't know about internals) You can sort-of mimic the issue by killing git at an inconvenient time in a large repo (e.g. docs .. maybe that's my problem, that I'm working with too-small repos). I don't have any creativity for using this app, though -- so I need something like a scenario, after all. Even if it's not entirely reproducible, knowing where to click (other than the "close window" button) to use the application realistically would help. Closing for now with "unable to reproduce" |