jj-vcs
FR: `jj file track/untrack` Should Open A Tui To Select Files
When running the command jj file track or jj file untrack a tui should be be opened to select which files to track and untrack. This also may be an opportunity to combine track/untrack into a single command with two flags that can be combined.
jj file track: Opens a gui to track and untrack filesjj file track -a [FILESETS]: Adds files to trackjj file track -r [FILESETS]: Untracks files- The last two flags can be combined together in a single statement as well
What exactly should this GUI display? If you display only the files added / modified in the working copy, the GUI is incomplete, because you can also untrack files that weren't modified in the working copy. But if you display all files in the repo, that's probably very cluttered.
I'd like a bit of a "user story" here. I don't know why I would ever need this, so please explain why you think someone else would.
I have snapshot.auto-track set to none() by default. Since I like to manually construct my revisions and no unintended files get included. So by default I'd like to see all untracked files.
This could be made toggleable. If so, additional toggle keys like m to see all modified tracked files and a to see all added tracked files could be useful as well. A fuzzy finder like fzf would be useful if there are a lot of files (maybe f). But all I "really" need is to be able to select untracked files quickly as that is biggest pain point.
That seems like the job of an external GUI to me. The default of snapshot.auto-track is all(), so the majority of users have no need for this. There are several GUIs for purposes that are more broadly useful than tracking files manually. I don't think it makes sense for the project to maintain a GUI upstream for this niche use-case.
I don't think this is very "niche", the one other person I know who uses jj changed this setting to none() after finding out about it as well. If the setting was more widely publicized I imagine more would too. I'm not sure on the general population that uses this setting though. I realized I said "gui", but what I really meant was "tui". Even for users who all() I see it being useful when they want to remove unintended added files before creating a new revision. I imagine the default toggles when the tui is activated could be set in the jj config
Yeah, I was assuming you meant TUI. I still have the same opinion. Also note that we have dynamic completions for these commands. So, we kind of already have this TUI. Its quality just depends on the shell you're using. There are many commands that accept paths as arguments, adding a custom TUI to select a path for each one doesn't seem like a good idea to me.
But do you see how it would help such a workflow? It is very popular VCS workflow. Almost all git integrated IDEs have a gui of added and modified files that allow you to add to staging because it is such a common thing. Many users I imagine prefer the way git handles tracking and not supporting such a thing will alienate them such as myself. Not auto tracking is one area I currently believe git does better than jj - see https://github.com/jj-vcs/jj/issues/323
But do you see how it would help such a workflow?
No. Just jj file track <Tab><Tab><Tab> and select the file you want to track via shell completions.
Many users I imagine prefer the way git handles tracking
I imagine most users prefer it the jj way. We're both just projecting our own preferences on other people. We either need to make a survey / study or stick to regular arguments, instead of appeals to popularity.
When I create a new file, I'm always aware if I want to track that in the repo or not. If I don't want to track it, I add it to .gitignore before creating the file. Otherwise, jj immediately starts tracking the file which makes it show up in the op log, allowing me to restore previous states of the "new" file if I mess something up. That's the job of a VCS well done: making sure you don't lose any work. Lastly, if you're yet unsure which commit to put the new file in, it is best to use jj split and jj squash to move the file between commits later.
No. Just
jj file track <Tab><Tab><Tab>and select the file you want to track via shell completions.
I find it interesting you think running a status command then typing out file names from that command with tab completion is easier than up/down arrow + enter, or can not understand how someone may not prefer this
I imagine most users prefer it the jj way. We're both just projecting our own preferences on other people. We either need to make a survey / study or stick to regular arguments, instead of appeals to popularity.
I imagine you may be correct and never said otherwise. I was just acknowledging a fact that more than one user prefers not auto tracking. I don't see it as an "irregular argument" since we are just discussing preferences in procedure.
When I create a new file, I'm always aware if I want to track that in the repo or not.
That’s great if that workflow fits you, but that isn’t always how people work in practice. In many real-world projects (especially larger ones or ones with generated assets, experiments, prototypes, etc.), files get created before deciding whether they should be tracked. Git users are extremely familiar with this workflow because “review + stage selected changes” is the dominant UX in both CLIs and IDEs. The idea of curating what goes into the next commit is a common VCS mental model many people rely on. Even for current users of auto-tracking it has not been a perfect experience - https://github.com/jj-vcs/jj/issues/323 https://github.com/jj-vcs/jj/issues/3493 https://github.com/jj-vcs/jj/issues/5225
I’m not arguing that JJ should change its defaults here—only that providing an ergonomic TUI for manual tracking would help the users who do prefer this mode. Shell completions don’t address the main pain point: it’s not about typing the filename; it’s about seeing the state of the working copy and selecting items interactively, which is exactly what staging UIs in Git tools provide.
The idea of curating what goes into the next commit is a common VCS mental model many people rely on.
I'm curious what benefit jj provides that makes you use it instead of Git.
Also, you can still do Git commands, and use jj for the parts that appeal to you. There are also a lot of Git tools which probably provide what you are looking for, but Git didn't change to accommodate those workflows. Similarly, it seems that jj could have its base model and other tools are built around it.
I find it interesting you think running a status command then typing out file names from that command with tab completion is easier than up/down arrow + enter, or can not understand how someone may not prefer this
What shell are you using? With fish, hitting tab twice will give you a nice list of files to select with arrow keys and enter, just like you suggest. I guess the only missing feature is selecting multiple files to track at once. The shell allows you to use globs of course. I suspect it's rare for people to track a set of files in one operation that cannot be easily expressed with a glob.
But anyway I think it's fine if you prefer a TUI for this. I just don't think the value proposition here justifies the burden to maintain this upstream. There's nothing stopping such a TUI from existing as a separate project.
In many real-world projects (especially larger ones or ones with generated assets, experiments, prototypes, etc.), files get created before deciding whether they should be tracked.
Generated assets should never be tracked. Always put them in a directory that's added to .gitignore. Experiments and prototypes should always be tracked. These files showing up in the op log will give you the confidence to change and delete things on a whim.
As mentioned, git doing something a certain way is not in and of itself an argument for jj to do the same thing.
I do think that #3493 and #5225 are good ideas.
What shell are you using? With fish, hitting tab twice will give you a nice list of files to select with arrow keys and enter, just like you suggest. I guess the only missing feature is selecting multiple files to track at once.
Bash, and I hope I wouldn’t have to change my shell for a vcs
The shell allows you to use globs of course. I suspect it's rare for people to track a set of files in one operation that cannot be easily expressed with a glob.
Most of my operations are not possible with globs since files aren’t tracked by default, so they are disparate.
Generated assets should never be tracked. Always put them in a directory that's added to
.gitignore.
Mostly yes, but sometimes they get generated before you can decide this. That is the point I’m getting at.
Experiments and prototypes should always be tracked. These files showing up in the op log will give you the confidence to change and delete things on a whim.
Disagree. You shouldn’t be forced to pollute your commit history with them if you don’t want to.
As mentioned, git doing something a certain way is not in and of itself an argument for jj to do the same thing.
That reductive point is not what was being made.
I'm curious what benefit
jjprovides that makes you use it instead of Git. Also, you can still do Git commands, and usejjfor the parts that appeal to you.
I currently do that in my collocated repos. I use git for adding to staging, committing, and branches (because I think git got this right). I use jj for rebasing, editing the commit history, searching, or any risky operations.
There are also a lot of Git tools which probably provide what you are looking for, but Git didn't change to accommodate those workflows. Similarly, it seems that
jjcould have its base model and other tools are built around it.
I think that’s an unfortunate view if that is what the jj maintainers believe. If the goal of jj is just to create a tool that the creators like. Then that’s fine. But if jj also has the goal to create a vcs to replace git and/or have wide adoption, I don’t think the “do it my way or go somewhere else” mentality will get it there.
But this chain and others are leading me towards the conclusion that jj doesn’t want to be the one vcs I hoped it could be (And that’s fine). So maybe I should just accept that and stop trying give feedback and change it.
I think that’s an unfortunate view if that is what the jj maintainers believe.
None of the maintainers have commented about it.
If the goal of jj is just to create a tool that the creators like. Then that’s fine.
That's why people give feedback...
I personally didn't like it, and don't understand why they added the config option for auto-tracking. From what I understood about the project, the auto-tracking everything was a main selling point of "never lose work", and a lot of the assumptions of how things work are based on that. Now that it's there, we've got file track and file untrack and lots of edge cases with ignore and track and what is auto-track set to. It's really too complicated for my taste (I think tools should lessen the burden on the human).
I really think there is not a
“do it my way or go somewhere else” mentality
I think a TUI for file selection is a big ask when there are already completions, and you are using an option that was an afterthought. See the page on community tools and you likely won't want this TUI anymore.