Option to customize working directory on tab (or pane) creation

[im-stuff]

Right now the split behavior is all contingent on the working directory of the original pane. This creates friction if you want to open a new pane for a different project. Especially if you are splitting off of a pane that has a worktree open, since conduit puts those in their own directory. Also any pane split off a worktree pane then gets treated as a worktree by conduit (with the delete and merge buttons), even if you change to a different directory.

I can't say I have a perfect solution, but maybe there could be a modifier key or something that changes the split behavior with regards to working directory of the original pane. Like: split pane but open in the root of the repo, or split pane but open in my DEV folder, etc.

Same goes for creating a new tab. I feel like new tab should start not in the working directory of the open tab, but in the user's preferred folder, especially since users are likely to use tabs as a logical separation between projects.

(I know, I could just cd but it feels clunky when I get dropped into the previous tab's wd when I'm trying to work on another repo...🤷‍♂️ )

[lostintangent]

Yeah I wonder if we could do something like...add a "New tab location" setting, that allows choosing: home directory, current directory (current behavior), or specific directory (you select a directory). We could then update the default to be home directory instead of current directory.

That seems pretty straight forward and logical to me. And I could whip that up today.

For the split terminal one, I personally like the current behavior, and unlike the tab setting, I'm not sure you'd want to define the split location globally. So this feels like something that would require a modifier key or whatnot (like you suggested).

[im-stuff]

The split terminal would be less of an issue (for me) if changing the terminal working directory such that you are no longer in a conduit-tracked worktree would free it from being a worktree in conduit's eyes. Once you've split a pane off a pane with a worktree, it becomes forever tied to the original pane, and clicking trash or merge on any pane closes all panes that were split off the original pane as well as the original pane, regardless of the pane's current working directory.

This actually reminds me of an issue I noticed which is the reverse, but would be fixed by the same change:

Right now if you need navigate to an existing worktree created by conduit, conduit doesn't recognize that you are back in one of its managed worktrees, so you don't get the contextual worktree action buttons. If those buttons (and the close pane behavior) were tied to working directory and git branch both issues would be solved.

[lostintangent]

Ah I see. Alright then I'll implement the tab setting we discussed above, and then plan to fix the worktree issue you mentioned as a means to address the terminal splitting behavior (to start). That feels right to me.

And as always, thanks for the incredible feedback here.