Why does't jj file untrack provide a -r option?

[arialdomartini]

AFAIK there is no way to run jj file untrack on a revset, like in

echo FILE > .gitignore
jj file untrack FILE -r @::

which would come in handy to ignore a mistakenly tracked file in @ and in all the descendants.

I wonder if it's because it is structurally not possible to have jj file untrack operate on revisions other than the current one, or for other reasons.

[jennings]

Kind of a nitpick, but I think "tracking" and "untracking" only make sense when applied to the working copy. Untracking means "remove the file from the repository but leave it in the working copy".

To remove a file from other revisions, jj restore -f root() -t REV FILE makes more sense to me, but it still doesn't support multiple revisions.

I have #9508 open for adding jj file delete -r REV PATH, that could support multiple revisions. I should clean that up to get it landed.

[arialdomartini]

Thank you @jennings: jj restore makes a lot of sense. It's a pity that it does not support multiple revisions. Any idea if this is a limitation that will be overcome anytime soon?

I think the use case I'm tackling is common. Say that the developer forgot to ignore a binary artifact directory bin and they kept committing, each revision having binary changes in bin. Then they realize they should have added ./bin to .gitignore since the beginning.

a-b-c-d-e-f-@

So:

• they jj edit a where ./bin was initially added
• they add ./bin to .gitignore

then, how to proceed? I thought, they could:

• jj file untrack bin. But this generates cascading conflicts in a's descendants, because each of them modifies the content of bin.
• jj restore -f root() -t @ bin would do the same.

What's the most correct approach?

[arialdomartini]

Maybe this?

jj squash -f 'a::' -t a bin
jj restore -f 'root()' -t a bin

although, honestly, I would find:

jj restore -f root() -t a:: bin

and

jj file delete -r a:: bin

more direct and intuitive. I even wonder if jj file untrack could have an option to propagate the deletion of untracked files, maybe with an option --update-descendants or the like.

[jennings]

I do agree that jj file delete -r a:: bin should work (when that command lands). I don't know any good reason for jj restore not to support multiple target destinations, but I wouldn't be surprised if there is one I'm not aware of.

Another way you can accomplish this today is:

jj run -r 'files("bin")' -- rm -rf bin

This is not a very efficient way of doing it (it will check out each revision just so you can run rm -rf bin on it).

You could also do a little shell scripting:

for id in jj log --no-graph -r 'files("bin")' -T 'change_id ++ "\n"'
do
  jj restore -f 'root()' -t $id bin
done