How do people work with jujutsu and hacks/secrets? Having no staging feels like a disaster magnet to me where things that should never be published have a chance to be saved and distributed by accident. I consistently have some temporary workarounds / scripts / credentials / logs hanging around my repos while I work on things. I think I'd have to change my approaches significantly to use this safely.
Things like logs are just generally ignored in gitignore so they can just be there or whatever. In practice this hasn't been a huge problem for me.
Hacks/workarounds/etc are actually pretty easy to handle and there are a couple strategies. The one I use is to use a merge commit. Let's say you have a patch P that you want to keep private (it hardcodes some build settings you like to use or whatever) and a patch A you want to work on. The base these changes are based off is B which is the upstream branch "main".
Then, you create a merge between A and P, creating commit M, and your working copy (called @ or "at") sits on top:
--> P -->
/ \
B (main) M --> @
\ /
--> A -->
And now, both `P` and `A` exist in your repository at the same time. Now, you can just use the `jj squash` command to take changes from `@` and put them inside either A or P, as you do your work, thus moving them "through" the merge commit M. These kinds of techniques where you move changes between commits are very common in Jujutsu so this is pretty natural once you get used to it.
Note that you can also have `M = @`, i.e. the merge commit is the working copy itself. I prefer to keep the commit M separate and work "on top" of it like in the above graph, because you may solve a conflict between P and A, and M would be the correct place to put it, and you would want to keep it separate from everything else.
A neat feature of this trick is that you can create a branch for change `A` and if you are sitting on top of `M`, and you run `jj git push`, then only `A` will be pushed and `P` will be ignored and left alone. In fact `P` will never be pushed unless you explicitly ask for it by creating the branch pointing to it. Nor is the merge commit ever pushed anywhere; it only exists so that you can have both changes available locally.
I do this all the time these days in various forms, and in practice, the day-to-day stuff isn't terribly different than it is when you just leave things out of the staging area inside your working copy.
I am a fan of the dev branch strategy [1], where I have a specific commit that holds all my customizations that I rebase off of. This blog post has it set up such that git automatically ignore pushing the dev commit, but I haven't really gotten that far yet. I just rebase my branch off current main when I'm ready to push.
