Browse history and merge parents

Applies to SiliconForge 0.1.2 · Updated 2026-09-30. Check platform limits.

Before this task: Understand working, staged and committed source →

Inspect immutable Git revisions and their hardware impact without switching branches or replacing your working files.

Start with an existing local history#

Open the repository root as a project and choose Changes, then History. If the project has no commits, use Stage and commit local changes first. Save current editor work before starting a working comparison; browsing a historical commit itself is read-only.

The navigator lists commits with their identity and display metadata. Selecting one compares that target commit against an immediate parent. The first commit has an explicit empty-tree baseline: its files were added relative to no tracked files, not relative to today's working directory.

Browse a ref, not a checkout#

1. Use the local branch/ref selector to choose a branch, remote-tracking ref or tag already available in this repository.
2. Select First-parent for the selected ref's mainline, or All reachable to include ancestors reached through every merge parent.
3. Use Load refs for further refs and Load older for further commits.
4. Use Filter commits to narrow the loaded entries by author, date or subject. Load more history before assuming an older match is absent.

This selector never checks out a branch. Your branch, index and saved working files remain where they were. A remote-tracking ref reflects the local repository's last fetched information; SiliconForge does not contact a remote just because you browse it. Fetch through your normal external Git client when required, then choose Refresh.

Worked flow: inspect a merge from both sides#

Suppose your local history contains a merge of a FIFO change into main. You want to distinguish what the merge introduced to main from what already existed on the feature branch.

1. Select main, choose First-parent, and select the merge commit.
2. Use the Parent menu to choose the first parent explicitly. Read both displayed identities. This comparison answers what changed relative to that parent.
3. Select Files to expand the exact file changes for this parent/commit pair. Select an RTL path to navigate to its retained source within the bound comparison.
4. Choose the other parent in Parent. Expect a different baseline and potentially a different change list, even though the target commit is unchanged.
5. Use All reachable to inspect the commits leading to the feature-side parent when you need its context.

A merge has multiple legitimate baselines; no single difference list is “the merge” without naming a parent. Do not infer approval or verification from Git's merge topology.

Read changed paths precisely#

The Files disclosure is tied to the selected immediate parent and commit. Rename entries retain old and new paths. A file selection should navigate to that exact retained path, not to a similarly named working file. File lists may require loading additional entries.

The Git path list and the hardware change list answer different questions. Git can record files outside the engineering snapshot's supported scope. If a changed path has no retained hardware source or diagram, inspect it in your external Git client; an absent diagram is not proof of an absent change.

When history changes underneath the view#

Another client may fetch, amend, commit or move a ref while you browse. If a cursor or HEAD is reported stale, choose Refresh, reselect the ref and commit, and verify the identities again. Do not reinterpret an old comparison as current working-state evidence.

If historical logic cannot be built, retain the commit IDs and inspect the available source and diagnostic. Do not substitute the live project's diagram for unavailable historical data. Continue with hardware review or state recovery.

Need help? Report an issue. Include your application version; never include credentials.