Summary
Toggling Preferences → ShowChangesInCommitDetailByDefault does not immediately change the default tab shown when selecting a commit. The Commit Detail panel keeps opening on the Information tab; the new preference only takes effect after reopening the repository.
Steps to Reproduce
- Open a repository.
- Open Preferences, check
ShowChangesInCommitDetailByDefault, confirm.
- Select a commit in the history.
Expected
The Commit Detail panel opens on the Changes tab.
Actual
The panel still opens on the Information tab. The preference only takes effect after closing and reopening the repository.
Root Cause
The preference is read in exactly one place — the CommitDetailSharedData constructor (src/ViewModels/CommitDetail.cs:24):
public CommitDetailSharedData()
{
ActiveTabIndex = Preferences.Instance.ShowChangesInCommitDetailByDefault ? 1 : 0;
}CommitDetailSharedData is constructed once per repository, when Histories is created (src/ViewModels/Histories.cs:195), and reused for the lifetime of the repository. When a commit is selected, the existing CommitDetail instance is reused and only its Commit is swapped (Histories.cs:483-492); Refresh() does not reset ActiveTabIndex. So ActiveTabIndex is effectively snapshotted at repository-open time and never re-reads Preferences afterward.
Additionally, ShowChangesInCommitDetailByDefault is a plain auto-property (Preferences.cs:126) — it does not raise PropertyChanged, so even a subscriber would not be notified of the change.
The Conflict (Maybe by design?)
ActiveTabIndex is stored in CommitDetailSharedData to remember the tab the user manually switched to across different commits. This shared state is the same field used to apply the "default tab" preference. Therefore the two concerns — "default tab from preferences" vs. "tab the user manually picked" — fight over one value: once the user switches to the Information tab, the shared ActiveTabIndex becomes 0 and overrides whatever the preference says, even after the preference is toggled.
A clean fix likely needs to separate these two concepts — e.g. a HasUserSwitchedTab flag so the preference default is only applied when the user has not manually switched.
Summary
Toggling Preferences →
ShowChangesInCommitDetailByDefaultdoes not immediately change the default tab shown when selecting a commit. The Commit Detail panel keeps opening on the Information tab; the new preference only takes effect after reopening the repository.Steps to Reproduce
ShowChangesInCommitDetailByDefault, confirm.Expected
The Commit Detail panel opens on the Changes tab.
Actual
The panel still opens on the Information tab. The preference only takes effect after closing and reopening the repository.
Root Cause
The preference is read in exactly one place — the
CommitDetailSharedDataconstructor (src/ViewModels/CommitDetail.cs:24):CommitDetailSharedDatais constructed once per repository, whenHistoriesis created (src/ViewModels/Histories.cs:195), and reused for the lifetime of the repository. When a commit is selected, the existingCommitDetailinstance is reused and only itsCommitis swapped (Histories.cs:483-492);Refresh()does not resetActiveTabIndex. SoActiveTabIndexis effectively snapshotted at repository-open time and never re-readsPreferencesafterward.Additionally,
ShowChangesInCommitDetailByDefaultis a plain auto-property (Preferences.cs:126) — it does not raisePropertyChanged, so even a subscriber would not be notified of the change.The Conflict (Maybe by design?)
ActiveTabIndexis stored inCommitDetailSharedDatato remember the tab the user manually switched to across different commits. This shared state is the same field used to apply the "default tab" preference. Therefore the two concerns — "default tab from preferences" vs. "tab the user manually picked" — fight over one value: once the user switches to the Information tab, the sharedActiveTabIndexbecomes0and overrides whatever the preference says, even after the preference is toggled.A clean fix likely needs to separate these two concepts — e.g. a
HasUserSwitchedTabflag so the preference default is only applied when the user has not manually switched.