`jj new` simply means "create a new commit [ontop of <location>]" - you don't have to describe it immediately. I never do.
I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.
I don't usually do that right away, but I often use squash or absorb to move additional changes into a commit I already made in my stack. I think the spirit still applies if you take that course.
You can switch an existing git repo to jj by using:
jj git init --git-repo my-repo
I think (but CANNOT PROMISE) that just removing the .jj folder will bring you back, but definitely take a backup of .git before you try this in case I’m wrong.
No that is correct when in colocate mode (which is the default mode). Simply removing the .jj folder will "de-jj" the repo entirely, but will leave you in a headless state. Simple to fix with a `git switch` though.
If you are _not_ in colocate mode, the .git folder is located _inside_ the .jj folder. So worth checking!
Tbf you wouldn't use/switch to jj for (because of) those kind of commands, and are quite the outlier in the grand list of reasons to use jj. However the option to use the revset language in that manner is a high-ranking reason to use jj in my opinion.
The most frequent "complex" command I use is to find commits in my name that are unsigned, and then sign them (this is owing to my workflow with agents that commit on my behalf but I'm not going to give agents my private key!)
jj log -r 'mine() & ~signed()'
# or if yolo mode...
jj sign -r 'mine() & ~signed()'
I hadn't even spared a moment to consider the git equivalent but I would humbly expect it to be quite obtuse.
Actually, signing was one of the annoying parts of jujutsu for me: I sign with a security key, and the way jujutsu handled signing was very painful to me (I know it can be configured and I tried a few different ways, but it felt inherent to how jujutsu handles commits (revisions?)).
If you need to type in a password to unlock your keychain (e.g. default behavior for gpg-agent), then signing commits one at a time constantly is annoying.
Does "own" try to sign working copy snapshot commits too? That would greatly increase the number and frequency of signatures.
I keep an eye on jaq, but there are some holes in the story. jaq 3.0 is faster than Linux distro builds of jq, but jq built correctly is faster than jaq. As far as I can tell the performance reputation of jq is caused by bad distro packaging.
Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.
Yes but it is easy to abuse/misuse IME, in that I think it requires one to maintain your own sense of discipline for the principle separation rather than the library/framework guide you into it. The threshold between UI and state management is comically easy to confuse.
Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.
That is the point. It is nonsense to delegate your responsibility to something that is neither accountable nor reliable if you care about not tanking your reputation..
Every time you run `wsl --install <distro>` you are creating a new VM. Every time you run `wsl --unregister <instance id or name/>` your are removing a VM.
It is these two operations at the heart of OP's app.
WSL2 distributions share the same Linux kernel. They only get their own root filesystem with a Linux userland (/bin, /usr, /lib etc), and some WSL config meta data. This is then stored as a virtual disk image (which is probably where your belief comes from). But the kernel runs in a single utility VM. The distros share that kernel instance and they are separated via namespaces only.
This makes running multiple WSL2 distributions in parallel very performant btw, as there is no world switch.
I stand corrected. It makes sense that it is a chroot/rootfs rather than fully independent VMs.
re: side-by-side running, I always get socket and/port port problems when doing that. Without having looked into it at all I figure it is NAT collisions.
Okay, are you guys using wrong terminology? Are you talking about a filesystem image as a "VM", because that would not be correct. A "Virtual HD" (VHD) is not a VM. Do you think a WSL2 distro instance is a "VM" because it's persistent? Did you know Docker containers can be persistent as well, people just choose as a best practice not to use it like that? Does that make them magical VMs?
WSL2 has a single VM running as the process vmmem (or vmmemWSL in the newest versions). This is the single Linux kernel that will be shared by every WSL2 instance. It will also be the instance that hosts Docker containers as well. I mean, I'm just echoing myself and apologies for the repetition, but this is just easily confirmed, utter factual truth.
A rootfs is not a VM. WSL2 and containers have different nuances about their filesystem and isolation (WSL2 instances is aware of other instances, for instance, as a design aspect, and WSL2 persists rootfs changes while docker as a best practices does not), but they're more alike than different. And they share little in common with something like VirtualBox or vmware, which actually isolate every such system as VMs.
Again, sigh, if you install 10 WSL2 "distros", you will have 10 rootfs overlays on your drive, and 10 persistence VHD files. When you run these the VM they all run under in the shared vmmem instance, which is the single utility Linux VM.
Is there a way to visualize this on a running system or some documentation that describes it? I'm not familiar with the plumbing here but did try to find some documentation.
"WSL 2 uses virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM). Linux distributions run as isolated containers inside of the WSL 2 managed VM. Linux distributions running via WSL 2 will share the same network namespace, device tree (other than /dev/pts), CPU/Kernel/Memory/Swap, /init binary, but have their own PID namespace, Mount namespace, User namespace, Cgroup namespace, and init process."
"WSL 2 runs all distros in the same utility VM, sharing the same Kernel."
If you run multiple distros take a look at the process manager and find the single vmmem or vmmemWSL (newer versions have the latter). That single instance is all of the instances, and all of the docker containers you might be running as well, each with namespace isolation (with WSL2 having intentional bridging between them for convenience). Visualise it by doing something intensive in any of them and seeing the single process react, because that's the single utility VM responsible for all of them. Further while starting up the first WSL2 instance or Docker container is expensive, requiring the initialisation of all of the resources for the utility VM and the memory to support it, subsequent iterations are much less expensive.
Thanks, it wasn't out of doubt that I asked, but it seemed having a reference to point at would help resolve the contention. The Docker blog post covered a lot more detail, even about WSL2, which was really informative and I hadn't seen.
I wonder exactly how much work "container" is doing in that Microsoft blog post's description, because it doesn't seem like it's the same kind of environment as a runc or containerd container?
I also wasn't quite sure how much detail to infer from the behavior of vmmemWSL or vmcompute.exe, because my casual understanding is that there's some adaptation layer that handles mapping Linux calls to Windows calls. It seems reasonable to allow for process mapping or accounting shenanigans for any number of good reasons.
>there's some adaptation layer that handles mapping Linux calls to Windows calls
This was how WSL1 functioned. It used a shim layer, and honestly it was pretty neat for a lot of the basic stuff. It fell apart if you were doing more complex/advanced stuff, however, as there were many missing cases and exceptions.
WSL2 instead uses that utility VM, with a couple of special Microsoft kernel drivers to interact with the host system.
`jj new` simply means "create a new commit [ontop of <location>]" - you don't have to describe it immediately. I never do.
I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.
reply