Symbolic links followed in project directory when launching external tool

[brainchild0]

If any directory element in a repository path is a symbolic link, and the terminal or file browser is launched as an external tool, then the present working directory of the tool features the links having been resolved. However, very rarely would the user want a path to be used other than by the literal path chosen to refer to the project.

I suggest the original path should be used in the external tool, without automatic resolution of symbolic links.

The steps to reproduce are as follows:

1. Create an empty directory.
2. Create a directory subtree, within the new directory, a/b/proj.
3. Initialize a repository in a/b/proj.
4. Create a directory x next to a, and create a symbolic link to a/b called x/y.
5. Open x/y/proj in SourceGit.
6. Open a terminal or file manager.
7. The PWD ends as a/b/proj, but desired is that is ends as x/y/proj.

[love-linger]

Actually, SourceGit just pass the x/y/proj to the terminal or file manager.

[brainchild0]

Would you clarify "just pass"?

Do you mean changing the current working directory?

I believe the behavior could be improved by also setting the environment variable PWD. The working directory of a process has a known limitation with preserving symbolic links. The problem is discussed in a question on StackExchange.

[love-linger]

Hover the repository's tab to see the path of it:

When open a file manager or terminal, SourceGit will just use it.

[gadfly3173]

Assuming you are using Linux, the relevant code in the project is as follows:

sourcegit/src/Native/Linux.cs

Lines 124 to 156 in d67c995

	public void OpenInFileManager(string path)
	{
	if (Directory.Exists(path))
	{
	Process.Start("xdg-open", path.Quoted());
	}
	else
	{
	var dir = Path.GetDirectoryName(path);
	if (Directory.Exists(dir))
	Process.Start("xdg-open", dir.Quoted());
	}
	}
	public void OpenTerminal(string workdir, string args)
	{
	var home = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
	var cwd = string.IsNullOrEmpty(workdir) ? home : workdir;
	var startInfo = new ProcessStartInfo();
	startInfo.WorkingDirectory = cwd;
	startInfo.FileName = OS.ShellOrTerminal;
	startInfo.Arguments = args;
	try
	{
	Process.Start(startInfo);
	}
	catch (Exception e)
	{
	Models.Notification.Send(workdir, $"Failed to start '{OS.ShellOrTerminal}'. Reason: {e.Message}", true);
	}
	}

This issue is essentially about operating system behavior.

On POSIX systems such as Linux, when setting the working directory for a process, the chdir() system call is ultimately invoked. The kernel implementation of chdir() automatically resolves all symbolic links in the path, making the process's current directory the real path.
Using startInfo.EnvironmentVariables["PWD"] = cwd to forcibly set PWD also differs from the actual effect of navigating with cd in a terminal emulator.

[brainchild0]

Hover the repository's tab to see the path of it:

Thank you for the suggestion. The path is showing with the links resolved. It seems SourceGit already followed them, which is different from the behavior desired. SourceGit should preserve the path provided by the user.

[love-linger]

SourceGit checks if the given path is under a valid repository and uses git rev-parse --show-toplevel to get the repository's root path. It means that we can not use the original args as the root of repository, and the final path is returned by git rev-parse --show-toplevel command

[brainchild0]

Using startInfo.EnvironmentVariables["PWD"] = cwd to forcibly set PWD also differs from the actual effect of navigating with cd in a terminal emulator.

Are you sure? If a shell opens a child shell, then the literal working directory from of the parent is preserved for the child. If the child were relying exclusively on the kernel's representation of CWD, then such preservation would be impossible. In fact, the path preservation can be disrupted by opening the child shell with an empty setting for PWD.

[brainchild0]

SourceGit checks if the given path is under a valid repository and uses git rev-parse --show-toplevel to get the repository's root path

I believe it would work if you query for the relative path (e.g. git revparse --path-format=relative --show-toplevel), and then apply the result to the literal path provided.

[love-linger]

I believe it would work if you query for the relative path (e.g. git revparse --path-format=relative --show-toplevel), and then apply the result to the literal path provided.

You can open multiple repositories in SourceGit, and this is a cross-platform app, on Windows, git rev-parse --path-format=relative --show-toplevel also returns the abs path if the repository is under a different disk.

[love-linger]

And what's more, in most cases, absolute paths are more stable (they won't be affected by the startup path of SourceGit) and easier to distinguish than relative paths.

[love-linger]

Additionally, personally, I prefer not to use relative paths for symbolic links to directories created with ln -s. Taking the example you mentioned above, what result do you expect from /x/y/proj/subfolder/../../../?

[brainchild0]

/x/y/proj/subfolder/../../.. resolves to /x.

I fail to understand the objections.

[love-linger]

I fail to understand the objections.

If you run cd /x/y/proj/subfolder first, and then run cd ../../../, after that are you sure you are still in x?

Sorry, you cannot even directly use paths like /x/y/proj/src without readlink