cli: show workspace roots in workspace list#9826
Conversation
ae85451 to
1f7e335
Compare
|
FYI @josephlou5, @yuja, and @pksunkara since you reviewed the original PR. I think this is a good idea. I haven't looked at the implementation yet. |
|
What's the rationale for this change? Is there any discussion? |
|
Linkin the discussion here I don't mind this being the default |
|
There's a little bit of discussion on Discord. The rationale is just that it seems like you would generally want to see the path, and you can pass a different template if you don't want it. Do you think it's a bad idea? I can see it being annoying for people who have the workspaces "far away" from each other so the relative path is long. |
|
The original PR I thought about wanting this to be the default, but went with the conservative approach rather than what I felt was the correct approach for most uses. |
|
I've pushed a fix for the Windows test failures to my fork. You can fetch/cherry-pick it from here: |
ecda826 to
600c908
Compare
|
This needs to be rebased |
Include each recorded workspace root in the default `jj workspace list` template instead of requiring users to opt in with a separate builtin template. The workspace path is generally useful when users have multiple workspaces and need to find the checkout on disk. Keeping this in the default output also avoids requiring users to know the template language just to answer that common question. Drop `builtin_workspace_list_with_root` now that `builtin_workspace_list` has the root-bearing output. Workspaces whose roots are not recorded or cannot be resolved are still listed without a path. Fixes jj-vcs#7114.
600c908 to
551c3a0
Compare
4 participants
Follow-up to #9713. This makes the root-bearing workspace list output the default and removes the now-redundant
builtin_workspace_list_with_rootalias.Fixes #7114.
Checklist
If applicable:
CHANGELOG.mdREADME.md,docs/,demos/)cli/src/config-schema.json)how it works, how it is organized), including any code drafted by an LLM.
an eye towards deleting anything that is irrelevant, clarifying anything
that is confusing, and adding details that are relevant. This includes,
for example, commit descriptions, PR descriptions, and code comments.