- All of everything good about it breaks down the instant you want to share work with the outside world. It's git on the backend! Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. And in doing so, you lose almost everything that gives it value in the first place - the elegant multi branch handling, anonymous commits, the evolog. Even if you want to work on the same project on two machines your only choice for this is without breaking everything via git is to rsync the folder. Yes, you can write alias to do all this like git. I might as well use git if I can't use the nice features.
- All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder. And then there is no way to ensure that it's purged (unlike in git) - the community response as far as I can tell is "Don't do this, never put a file that isn't in gitignore".
- And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored, is all part of your immutable history, and disappears if you ever switch off of that new commit state.
> Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match.
All true. I ended up writing my own `jj push` and `jj pull` aliases that automated all this. They aren't simple aliases, but it worked. `jj push` for example "feels" very like `git push --force-with-lease`, except if you've stacked PR's it pushed all branches your on. It hasn't been a problem since.
I ended up wondering if they deliberately left the `jj pull` and `jj push` commands unimplemented just so you could write something custom.
> All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder.
jj abandon COMMIT && jj git garbage-collect
> And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored
> True, but how is this different to any other VCS?
What other VCS behaves this way by standard? If it's not in e.g. .gitignore "git status" will show that it's aware of it, but won't automatically absorb them into the commit? https://github.com/jj-vcs/jj/issues/5596 doesn't seem to be the oldest instance of this problem, but does seem to be the current discussion, and there seems to be no consensus on how to fix.
> https://github.com/jj-vcs/jj/issues/5596 doesn't seem to be the oldest instance of this problem, but does seem to be the current discussion, and there seems to be no consensus on how to fix.
Ahh, sorry - I didn't understand the issue. Yes, that is going to catch you unawares.
I can't see a better solution than a warning. It looks to be an unavoidable negative side effect of jj's auto-commit behaviour, but auto-commits bring so many positives I'll wear the occasional stray add. Usually they are harmless and trivial to reverse - but I've made a mental note to revise my jj workflow. When I change .gitignore, do it in the oldest mutable commit.
> Oh, and ISTR submodules were a pain to work with.
Yes, they are, although that's no different to git. JJ's tracking of submodule hashes in the parent repository behaves exactly as you would expect. What jj doesn't have is a command to bring the submodule into sync with the parent repository, like git's submodule command.
However, I find git's submodule command behaviour borders on inexplicable at times. I wrote my own `jj submodule` alias that does one simple job - it checks out every submodule the parent repository owns, at the hash recorded by the parent. I find that far better than the git command, which follows the usual git pattern of being a complex mess of sub-sub-commands with a plethora of options.
If jj automatically recursively updated submodules when you moved to a different change-id, it would be most of the way there. If it added commands to add and remove submodule directories, it would be there, and the reasons people dislike git's submodules would be gone.
Or, ask it to make a plan, and it makes a good plan! It explicitly notes how validation is to take place on each stage!
And then does every stage without running any of the validation. It's your agent's plan, it should probably be generated in a way that your own agent can follow it.
Besides the problem caused by reflections and by the fact that unless you are very close to the transmitter you do not receive a direct wave but one reflected from the ionosphere, there is an additional difficulty.
Antennas with high directivity, which are needed for accurate triangulation, must be very big in the shortwave range (wavelength from 100 meter to 10 meter). Moreover, if they are too big it would be difficult to move them, to be able to measure an angle.
So traditional triangulation is inaccurate in this frequency range.
With modern technologies, using highly accurate synchronized clocks, one could distribute shortwave antennas over a large area, to create a synthetic aperture array, enabling a precise triangulation. However this would be expensive. An amateur would certainly not have such a thing. I doubt that even a state would bother to build such a thing, because it would not be worthwhile.
While precise triangulation of a shortwave transmitter from far away is very difficult, such a transmitter would not be hard to find during a local search wherever it is placed, because there not only the direction, but also the intensity gradient of the signal would allow finding it.
Two receivers of the same signal may not be from the same proximate source. One could from the original antenna the other from a reflection. Both could be reflected but by different reflectors. Even if the proximate source was the same for both the receivers, triangulation might yield the location of a virtual image of the original source.
BTW I am just going by geometry and may be way off because radiowaves behave quite differently compared to visible light.
One might need effectively the inverse of beamforming to nail it.
It’s good-faith arbitrage. Until everyone automatically suspects everything to be LLM generated and there is zero trust, anyone doing this is eroding the good faith that lets them get away with it in the first place.
reply