How does that work in practice, is there a daemon running constantly and monitoring? How does that interact with other users and changes from other computers?
How does that work in practice, is there a daemon running constantly and monitoring? How does that interact with other users and changes from other computers?
You can't change example.com/foo to point to example.com/baz and have it exist in source control. So to make the change you have to ignore every file that contains that string, test, then unignore. Or you have to make sure to absolutely remove every reference you've added to the merkle tree. Or you have to completely nuke your source control database after testing.
If you buy a used laptop hard drive from a remote worker at $BIG_REGULATED_CO because you want to find exploits, you're probably happier if they run jujutso than git because there will be a higher probability of finding secrets, client info, and other things that are forbidden from going into source control.
I don't see a problem with secrets TBH. .gitignore is respected if that's what you have in mind. Otherwise store your secrets out of tree (you probably should with git too, anyway.)
It's more that there isn't really a big difference between the workflow of
# you're on
staging area
@ commit A
# make some untracked changes and console logs you don't wanna commit
git add -p && git commit # select only what you want
vs # you're on
@ empty commit
| commit A
# make some local changes (which are tracked in @)
jj commit -i # select only what you want
You're still "in charge what gets tracked" if you treat the last @ commit as your local playground, exactly the same as the staging area.
The only difference is that you can use exactly the same tools to manipulate your "staging area" as other commits.
The only difference being that you can manipulate your staging area with the same tools as any other commit.