FR: Change new worktree location

[yrtimiD]

From what I understand from the code, addRemoteWorktree will try to put a new worktree in the workspace root path. So, the new workspace folder will essentially be inside a main repo, which feels weird to me. I usually put different workspaces side by side under same root folder, like this:

projects/projX/master    // git repo root
projects/projX/featureA  // worktree for the featureA

so, essentially a new worktree folder location is calculated like: dirname `git rev-parse --show-toplevel` + ${newBranch}

Any chance to have this configurable in the extension (also for new worktree branches)?

[alexiszamanidis]

Hi @yrtimiD,

The main idea is that you have the worktree you are currently working on open in VSCode. The new worktree you want to add will be created one level above.

Example:

Imagine you have opened the featureA worktree in VSCode.

/projects/repo1/featureA

If you want to add featureB worktree, it will be created as shown below:

/projects/repo2/featureB

But the truth is that if you have opened a folder inside your worktree (e.g. /projects/repo1/featureA/folder1), it will create the new worktree inside the featureA folder(/projects/repo1/featureA/featureB).

I'm not sure why anyone would do this, but it would be great to use your worktree path calculation to handle these situations.

Thank you for your contribution. I will try to enhance the current implementation as soon as possible.

[yrtimiD]

My "current folder" is 2 level below because we have a big monorepo with many workspaces under different levels, so using git root instead of current folder should be more robust.

[alexiszamanidis]

Hmm.. that's the case. Good to know!

I implemented the enhancement and it is published.

Please let me know if everything goes well!

[yrtimiD]

Yes, the location is now as I'd expect it! Thanks for fast fix! There are other issues I observe now, will open separate issues or PR's if you don't mind. BTW, any chance you can add logging to executed git commands so it will be easier to diagnose various problems?

[alexiszamanidis]

You are welcome!

Sure, I will add logging for the git commands.

Please let me know if you need anything else. It's my pleasure to have people contribute to my projects.

Thank you again for your time and contribution!

[alexiszamanidis]

Hi @yrtimiD,

Logging has been added for the commands.

The main idea is that all commands should be executed by the executeCommand function. This function handles the error message if something goes wrong. Current format: command: '${command}'. Error: '${e.message}'.

Please let me know if this is something you like or have better ideas to improve it.

[yrtimiD]

Yes, this is definitely helps as vscode popups the whole error message as error notification. I use multi-part branches, like 'projX/bugfix/123' and I suspect that the add command is executed with only the last part (i.e. "123"), so I'd like to see the log for successful commands too. Maybe it will be easier to just debug the extension :) UPD: probably found the issue, added details in a #13

Found another small issue with the command I gave you (the git rev-parse --show-toplevel). If multi-part branch names are used (projX/bugfix/123) - the worktree will be created with all the parts as subfolders, and it's great. But, if extension's worktree add command is invoked while in the other worktree, the "show-toplevel" will return worktree's top level, and not the main one where main .git folder is. This will lead to weird nesting of folders...

looks like there is another, more robust way of detecting proper root folder: git rev-parse --git-common-dir --path-format=absolute it returns location of the main .git folder regardless to current folder or worktree. So, we can assume that going 1 level up will give us main branch root, and one more folder up - good location for other worktrees.

I can try to visualize this if explanation is complicated.

[alexiszamanidis]

When I execute this command:

git rev-parse --git-common-dir --path-format=absolute

It seems that the --path-format has no effect on the output(even with the relative value).

• In the common directory it returns .git.
• In a worktree it returns the absolute path.

Does it happen on your system? Do you believe this is an issue we should handle?

Last but not least, the solution for the path will look something like this.

dirname (dirname $(git rev-parse --git-common-dir --path-format=absolute))

Is this right?

[yrtimiD]

checked in the manual, was surprised to discover that position of path-format is important and it should appear before the flag it expected to affect, so in our case next should always return absolute path (tested in my system): git rev-parse --path-format=absolute --git-common-dir

Regarding dirname, if vscode actually executes it in the shell - by using dirname command you'll prevent Windows users from using your extension. I'd recommend doing all filesystem manipulations with node's path library.

[alexiszamanidis]

Ah, position matters.

Yes, I will execute it through the node file system. I just wanted to show you the formula of path calculation.

[alexiszamanidis]

The enhancement has been published!