Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: Make jj file untrack work with files that are not ignored #5225

Open
AngelEzquerra opened this issue Jan 1, 2025 · 4 comments
Open

FR: Make jj file untrack work with files that are not ignored #5225

AngelEzquerra opened this issue Jan 1, 2025 · 4 comments
Labels
enhancement New feature or request

Comments

@AngelEzquerra
Copy link

AngelEzquerra commented Jan 1, 2025

Is your feature request related to a problem? Please describe.
Currently, if you do jj file untrack on a file that is not being ignored, the command is effectively a "no op" since the files are immediately, automatically and silently tracked again. This is extremely surprising and also makes keeping files outside of the repo (but in the working directory) harder than it could be.

Describe the solution you'd like
When the using jj file untrack on a file is not already gitignored, jujutsu should store the fact that the user explicitly requested to untrack that file, and not track it automatically until the user used jj file track to track it again.
How to store that information is debatable. I think it should not be added to the "public" .gitignore, to avoid sharing with others the existence of that untracked file. It could perhaps be stored in .git/info/exclude (which IMHO would be a much better solution than storing it in the public gitignore). But given that .git does not automatically track any files, maybe it would make more sense to store this info in an "jujutsu specific", local ignore file (e.g. .jj/info/exclude)?

Describe alternatives you've considered
I think this behavior should be automatic, but an alternative would be to require the user triggering this behavior by adding a flag to jj file untrack (e.g. jj file untrack --save). I think this might only make sense if jj updated the git exclude file (but not if it created it's one jj specific file to store the list of untracked files). Also, this would still result in jj file untrack (without the flag) having surprising "no op" behavior.

Additional context
This is related to #323.

@PhilipMetzger PhilipMetzger added the enhancement New feature or request label Jan 1, 2025
@arxanas
Copy link
Contributor

arxanas commented Jan 2, 2025

One alternative could be to save a negative pattern to the sparse checkout rather than modify any ignore files.

  • I didn't seriously think through the implications.
  • Currently, sparse checkouts can only have positive patterns, but the v2 design document discusses negative patterns.

@yuja
Copy link
Contributor

yuja commented Jan 2, 2025

Maybe dup of #3493 ?

iirc, there were other related discussion about newly-unignored files on jj new <REV> somewhere. If it's addressed in a way that working copy remembers cumulative list of temporary untracked files and directories (as we do for Git submodules right now), jj file untrack could update the list.

@AngelEzquerra
Copy link
Author

Maybe dup of #3493 ?

It's very similar. The only difference is that I think it'd be best to not use a git ignore file, since the list of files that have been "jj untracked" is jujutsu specific so I don't think it should change the git config (since git does not auto-track any files). Maybe both could be combined? e.g. jj file untrack could keep track of the untracked files in jujutsu, but if you also add --ignore (as #3493 suggests) it could then also add the files to the closes git ignore file? Not sure if that'd be useful though...

@yuja
Copy link
Contributor

yuja commented Jan 2, 2025

the list of files that have been "jj untracked" is jujutsu specific

That probably depends on user's workflow. I would add it to .gitignore or global ignore if the file isn't supposed to be version controlled.

Maybe both could be combined?

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants