Settings changed in sub-worktrees are lost when restarting SourceGit

[goran-w]

EDIT: This issue started as "Filtered log-graph loses some valid merge-lines" which was a mistake on my part. However, it was soon discovered that my per-repo/worktree settings had been changed unexpectedly on restart of SourceGit, so this issue is now re-opened to handle that problem.

---

(Old Description below...)

Even though two related branches are both included in the "Visibility in Graph" filter, merge-lines between them are not drawn.

See example here, where I've added the missing (but expected) merge connections in green:

(NOTE: I've confirmed that the SHA from the 2nd parent of these two '+' merge-points match the SHA of the indicated commit on the opposite branch.)

[love-linger]

Check if --first-parent is toggled?

[goran-w]

Yes, sorry! I'm a fool... 😂

[goran-w]

@love-linger Actually, I'm experiencing that I turn off --first-parent, but at some later time it gets re-enabled without me activating it willfully. Happened a couple of times already, since my last comment. 🤔 Is there some feature/bug in SourceGit that could cause this?

[love-linger]

Never seen this bug. However, if SourceGit does not exit normally after changing the settings, the changes will indeed not be saved successfully (because $GIT_DIR/sourcegit.settings is only saved when the repository is closed or the program exits normally). For example, in the following conditions, the repository settings will not be saved:

• Stop debugging from IDE (not by quiting app normally)
• Crash
• Process was killed

[goran-w]

Yes, that makes sense. I'll keep a lookout for this, in case it re-appears...

[goran-w]

@love-linger Hmm, actually something else is at play. I'm starting SourceGit, disabling "First-parent only", closing SourceGit, verifying that preference.json has been re-saved, starting SourceGit - now the "First-parent only" option is enabled again.

Where is this setting supposed to be persisted, and under which name?

[love-linger]

First-parent only is a per-repo configuration that is stored in $GIT_DIR/sourcegit.settings with key HistoryShowFlags

[goran-w]

Aha - now we're getting somewhere! I'm currently doing this in a worktree, which means that .git is not a directory but a config file specifying a gitdir: variable pointing to <orig_clone_dir>/.git/worktrees/<curr_worktree_dir>/. ⚠️

There is a sourcegit.settings file in <orig_clone_dir>/.git/ but none in <orig_clone_dir>/.git/worktrees/<curr_worktree_dir>/.

When I change the setting within the worktree-tab and then close SourceGit, the new value(s) are seemingly not saved anywhere!

If I switch tabs to the <orig_clone_dir> tab and change the setting, it's getting saved there (under <orig_clone_dir>/.git/). If I then re-open SourceGit, the <curr_worktree_dir> tab seems to have loaded the settings from the original clone.

Could it be that settings are loaded from, but not saved to, the original clone's top-level .git/ when working in a worktree?

I suppose there are two ways this could work:

• Load AND save settings in the original clone's top-level .git/ folder, even when working in a new worktree (this would sync settings between the original clone and any of its worktrees).
• Load and save worktree settings in their respective worktree-gitdir, i.e <orig_clone_dir>/.git/worktrees/<curr_worktree_dir>/ (this would let each worktree use different per-worktree settings ).

I'm not sure which of these two approaches is most preferable, and IMHO it doesn't matter much - as long as any changed settings are correctly re-loaded when restarting...

[love-linger]

I know.

Currently, there're two types of per-repo settings:

• Shared between all worktrees. Stores in main worktree's $GIT_DIR, and only saved when it is changed in the main worktree
• Each worktree has its own settings. Stores in $GIT_DIR/worktrees/<worktree_name>. For example: History filters.

[love-linger]

sourcegit/src/ViewModels/Repository.cs

Lines 516 to 537 in 080c446

	public void Close()
	{
	SelectedView = null; // Do NOT modify. Used to remove exists widgets for GC.Collect
	Logs.Clear();
	if (!_isWorktree && Directory.Exists(_gitCommonDir))
	{
	try
	{
	if (_workingCopy.InProgressContext != null && !string.IsNullOrEmpty(_workingCopy.CommitMessage))
	File.WriteAllText(Path.Combine(GitDir, "MERGE_MSG"), _workingCopy.CommitMessage);
	else
	_settings.LastCommitMessage = _workingCopy.CommitMessage;
	using var stream = File.Create(Path.Combine(_gitCommonDir, "sourcegit.settings"));
	JsonSerializer.Serialize(stream, _settings, JsonCodeGen.Default.RepositorySettings);
	}
	catch (Exception)
	{
	// Ignore
	}
	}

[goran-w]

The "only saved when it is changed in the main worktree" is very confusing and frustrating.

It should be changed, so that sub-worktrees sync their settings to the main-worktree and they get saved there (in the common .git dir) on shutdown.

[love-linger]

only saved when it is changed in the main worktree

I think I didn't explain it clearly. Actually, all worktrees of the same repository will load the $GIT_COMMONDIR/sourcegit.settings file when opened. This means that each worktree has an independent runtime instance of RepositorySettings. Currently, changes between these instances cannot be synchronized. You can also understand it this way: changes in the main worktree only define the state of other worktrees when they are just opened.

[goran-w]

Surely there must be a way to fix this. The current behavior is not acceptable, IMHO.

Since the state can be "pushed down" from the main-worktree to sub-trees on startup/open, it should (by "symmetry") be possible to trigger a "pull up" of settings from a sub-tree to the main-worktree whenever they are changed in that sub-tree?

Alternatively, the main-worktree and sub-worktrees could be using a single common instance of RepositorySettings?