There's an anti-footgun heuristic that asks "are you sure", basically, if the file about to be tracked is >=1mb, saved a lot of asses a lot of times.
But also, if it is such a showstopper, you can disable auto-amend of _new_ files with snapshot.auto-track=none() config (or even something funky like src/*) - and recently jj status finally started showing untracked files too, it's very usable
It's hilarious that there are people who "don't get what problem jj is trying to solve".
It seems like they just use git so little, barely for more that linearly committing, so they are not aware of it's shortcomings that jj often elegantly fixes.
I guess you could question the specific example, but to me the question sounded like "why would you do rebases".
Like, for various reasons?.
The point was that it's way easier and way safer to do rebases in jj, and it straight up allows to do complex stuff like the mentioned example easily and inderstandably, idk
You can set `snapshot.auto-track` config to "none()" (which is a fileset, so you could actually have something like src/* there).
That way, only files that were already present in the wc commit are amended, and new files are kept untracked until you explicitly `jj file track` them.
And jj status finally fully shows them in the main branch too (it's broken in the v0.26 release sadly)
While I understand your predicament, consider not giving up on jj just yet because of this.
It is _exceedingly_ hard to lose files in jj, it's actually emotionally frustrating reading the line "most important thing [..] is to never ever delete file" because that's the whole shtick in jj with the oplog and whatnot - so something like nuking secrets completely from a jj repo is a bit of a chore.
Can you file a bug at least? A repro of some sort?.
Or at least show us what is it what you did, `jj op log` might be enough to deduce what happened.
Also check out `jj op log -p`, your files might very well be in history, especially if, as you said, jj status took a long time (presumably snapshotting those files that got lost)
In git terms (this is an analogy that is a bit wrong, but useful here), doing `jj new` after making some changes is the same as doing `git commit -am ""` then.
Would you expect `git status` to "show you the changes, full stop" then?.
Where the hostility is coming from, ugh
Why is it so hard for people to even consider for a minute that they might be wrong or confused - nooo, this tool that was in development for years by at least one full-time google employee with a decade of mercurial dev experience and a ton of contributors, and that is loved by a lot of people already for it's simplicity and functionality - definitely failed in such a basic task, it's not you misunderstanding some basics in how it works, definitely, "full stop".
Another thing is that you might have set a `snapshot.auto-track="none()"` config and never told us, which is an opt-in way to disable autotracking, and which `jj st` does not support fully (if at all in released version) yet - then you totally "opted in" being lied to, sorry.
Give it a try, but also know that git branches and _topological_ branches are different things