mattcasters commented on issue #7520: URL: https://github.com/apache/hop/issues/7520#issuecomment-4978454444
## Root cause analysis (follow-up to the screenshots / logs) Thank you for the detailed repro steps and screenshots — they were enough to pin this down more tightly than the original “JGit vs native optimization files” theory. ### What the new evidence shows | Observation | Implication | |-------------|-------------| | Missing id is always **`43d95f23121db40b3c8dddf78f272de30bee3d7c`** | That is **admin/Test** HEAD (as shown in Gitea), not a random corrupt id | | On the Gitea bare repo: `git cat-file -t` → `commit`; `fsck` clean after reflog cleanup | Object exists on the server side | | Global git config already has `core.commitGraph=false`, `core.multiPackIndex=false`, bitmap write/use disabled | commit-graph / midx / bitmap incompatibility is **not** required to explain the failure | | Stack: `GitGuiPlugin.rootChanged` → `GitPerspective.refresh` → `updateGui` → `isCommitInCurrentBranch` → `RevWalk.parseCommit` | Failure is on **project/root switch**, not on opening a pack format | | Adding **edp_meta** still reports the **last commit of admin/Test** | Cross-project / stale UI state | Note: the `cat-file` / `fsck` run in the screenshots was on the **Gitea container bare repo**. That proves the server has the object. It does not by itself prove the Windows working clone under `F:\WorkSpace\Hop\hop_repo_2181\Test` is healthy — still useful to confirm client-side if anything remains odd after the Hop-side issue is fixed — but the stack + multi-project behaviour already point at a Hop bug. ### Primary root cause: stale Git Perspective selection after repository switch The Git Perspective is a **long-lived singleton**. History table rows hold **`RevCommit` instances** (object ids) from whatever repository was active last. On project change, `GitGuiPlugin.rootChanged()` replaces the active `UIGit` with a **new** repository, then calls `GitPerspective.refresh(false)`. `refresh()` currently calls **`updateGui()` first**, while the history table still has the **previous** project’s selection: 1. Project **Test** is active → history selection is HEAD `43d95f…`. 2. User switches to / adds **edp_meta** (small repo; does not contain Test’s commits). 3. `rootChanged` opens **edp_meta**’s `.git`. 4. `refresh()` → `updateGui()` → `getSelectedCommit()` still returns Test’s `RevCommit`. 5. `isCommitInCurrentBranch()` does `walk.parseCommit(commit.getId())` against the **new** object database. 6. Result: `MissingObjectException: Missing unknown 43d95f23121db40b3c8dddf78f272de30bee3d7c`. That matches: - the log line `Error checking if commit is in current branch` - the stack through `isCommitInCurrentBranch` / `updateGui` / `refresh` / `rootChanged` - “error related to the last commit of admin/test” while dealing with **edp_meta** Relevant code path (conceptually): - `GitGuiPlugin.rootChanged` — opens new repo, then refreshes the perspective - `GitPerspective.refresh` — calls `updateGui()` **before** clearing/rebuilding the history table - `GitPerspective.updateGui` — reads `getSelectedCommit()` from the **still-populated** table - `GitPerspective.isCommitInCurrentBranch` — re-parses that id against the **current** `Repository` `Missing unknown` means JGit looked up the object id in the **currently open** ODB and did not find it. That is expected if the selected id belongs to **another** repository that was active a moment earlier. This path is **new in 2.18** with the Git Perspective (#6914 / #7053). It did not exist in 2.17 in this form. The concurrent JGit 7.3 → 7.5 bump is **not** required to explain this failure mode. ### Secondary observations (not the main stack, but real) 1. **Previous `UIGit` is not closed** when `rootChanged` does `git = null` and opens a new repo. On Windows, abandoned file handles plus a startup native-git sync script (pull/rebase/gc/lock cleanup) can add noise or races — secondary to the selection bug above. 2. **Invalid reflog entries** on the bare repo (`dc7d4355…` / Initial commit) are a server hygiene issue; after cleanup, `fsck` was clean. Unlikely to be the direct cause of Hop’s `parseCommit` on the client path described above. 3. **Error handling** in `isCommitInCurrentBranch` logs a full ERROR stack and returns `false`. So a stale cross-repo selection looks like a severe JGit regression even though it is only used for toolbar enablement (e.g. cherry-pick). ### What this is *not* - Not primarily “JGit 7.5 cannot parse native Git commit-graph / multi-pack-index / pack bitmaps” — those are already disabled in the reporter’s global config, and the missing id is a concrete commit from **another** project’s history selection. - Not explained solely by Gitea server object corruption: the same SHA is present and typed as `commit` on the server after the reported cleanup. ### Summary **Root cause:** On project / explorer root change, Git Perspective runs branch/commit UI logic against a **stale history selection** from the **previous** repository, using the **newly opened** JGit `Repository`. That produces `MissingObjectException` for object ids that are valid in the old repo (e.g. Test HEAD `43d95f…`) but absent from the new one (e.g. edp_meta). We’ll address the fix in a follow-up PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
