I really recommend just ripping off the band-aid and using jj "as intended". It took me only a day or two to adapt, and a week to feel like I am now a jj native. It's really a tiny cost to pay, and way less than the overhead of maintaining a bidirectional mental mapping between jj and git.
I don't get git. Every time it's posted people gush about how git enables some super complicated workflow that I can't wrap my head around. I have a simple edit/undo workflow in my editor that has served me well for decades so I guess I don't understand...
There is a limit to how far one needs to abstract personally.
I don't layer my utensils for example, because a spoon is fit for purpose and reliable.
But if I needed to eat multiple different bowls at once maybe I would need to.
For my personal use case, git is fit for purpose and reliable, even for complex refactoring. I don't find myself in any circumstances where I think, gosh, if only I could have many layers of this going on at once.
Even if you're working on one single thread of development, jj is easier and more flexible than git though. That it works better for super complicated workflows is just a bonus.
jj reduces mental overhead by mapping far more cleanly and intuitively to the way people tend to work.
This is a little weird at first when you’ve been used to a decade and a half of contorting your mental model to fit git. But it genuinely is one of those tools that’s both easier and more powerful. The entire reason people are looking at these new workflows is because jj makes things so much easier and more straightforward that we can explore new workflows that remove or reduce the complexity of things that just weren’t even remotely plausible in git.
A huge one for me: successive PRs that roll out some thing to dev/staging/prod. You can do the work all at once, split it into three commits that progressively roll out, and make a PR for each. This doesn’t sound impressive until you have to fix something in the dev PR. In git, this would be a massive pain in the ass. In jj, it’s basically a no-op. You fix dev, and everything downstream is updated to include the fix automatically. It’s nearly zero effort.
Another is when you are working on a feature and in doing so need to add a capability to somewhere else and fix two bugs in other places. You could just do all of this in one PR, but now the whole thing has to b reviewed as a larger package. With jj, it’s trivial to pull out the three separate changes into three branches, continue your work on a merge of those three branches, and open PRs for each separate change. When two of them merge cleanly and another needs further changes, you just do it and there’s zero friction from the tool. Meanwhile just the thought of this in git gives me anxiety. It reduces my mental overhead, my effort, and gives overburdened coworkers bite-sized PRs that can be reviewed in seconds instead of a bigger one that needs time set aside. And I don’t ever end up in a situation where I need to stop working on the thing I am trying to do because my team hasn’t had the bandwidth to review and merge my PRs. I’ve been dozens of commits and several stacked branches ahead of what’s been merged and it doesn’t even slightly matter.
If you think about it, git is really just a big undo/redo button and a big "merge 2 branches" button, plus some more fancy stuff on top of those primitives.
"Merge 2 branches" is already far from being a primitive. A git repository is just a graph of snapshots of some files and directories that can be manipulated in various ways, and git itself is a bunch of tools to manipulate that graph, sometimes directly (plumbing) and sometimes in an opinionated way (porcelain). Merging is nothing but creating a node (commit) that has more than one parent (not necessarily two) combined with a pluggable tool that helps you reconcile the contents of these parents (which does not actually have to be used at all as the result does not have to be related to any of the parents).
(you may know that already, but maybe someone who reads this will find this helpful for forming a good mental model, as so many people lack one despite of working with git daily)
Based on just simple math there was basically no chance of turnout being over 2.5m and yet the market for multiple days had the higher buckets at exorbitant prices.
Apple products last longer, retain their value longer, and are supported longer than their peers virtually across the board.
AppleCare is extremely cheap and comprehensive. I have had one Apple product fail in at least fifteen years and it was replaced without hesitation. It’s been nearly a decade since I’ve had an iPhone screen crack from dropping, and that used to be a regular occurrence. And if I do, again, it’s covered under AppleCare.
There are many harsh criticisms to be leveled against the company. This is not one of them.
Not just insider information, but insider access. If the outcome of some prop bet is under the control of a handful of people, those people can trivially conspire to produce whatever outcome is most profitable to them.
If the outcome of a prop bet really is fully controlled by insiders, so that those insiders are making decisions based on betting outcomes, then allowing that betting to occur seems antisocial and counterproductive to begin with. This is another problem with the Polymarket/Kalshi species of "prediction market".
The problem is it's pretty hard to tell ahead of time whether that's what happens.
Suppose some large private company has to decide whether they're going to build a new facility in city A or city B. This is useful information for all kinds of reasons. If you're a vendor then you need to start making preparations to set up shop in the city where your big customer is moving etc.
The company's analysis shows it would derive a $10M advantage from building in city A. The prediction market is correctly leaning that way. If there are only enough counterparties that someone who now bets on city B and wins would make $5M, everything works the way it should and the company goes with city A. But if there are enough counterparties that a winning bet on city B would net you $25M then the company can place the bet, eat the $10M loss by choosing city B and come out $15M ahead.
But the $10M number isn't public. It's essentially the thing you wanted the market to predict and it could be arbitrarily larger or smaller than that. So how are you supposed to know if the prediction market will be predicting the result or determining it?
A private company of any real size isn't plausibly going to choose Atlanta over Chattanooga to win a prediction market bet. This is a good example of the kind of prediction that can theoretically be prosocial, and one strong indicator that it might be is that an insider bet is helpful rather than harmful.
On the other hand, at the point where the prediction market winnings are material enough that they might alter the underlying decision itself, you've clearly got an antisocial structure. Prediction markets that don't want to be seen as mere prop betting venues should refuse to run markets on those questions.
> On the other hand, at the point where the prediction market winnings are material enough that they might alter the underlying decision itself, you've clearly got an antisocial structure.
How is that supposed to be determined?
There are many decisions that have only minor implications to the party making them (they're choosing between two nearly-equivalent alternatives) but massive implications for third parties (the company or city chosen gets a huge gain and knowing which one is valuable information). When the decision itself is essentially a coin flip, any prediction market winnings could alter the underlying decision. And whether it's that close of a decision is the thing the market would be trying to predict rather than something you already know.
A different example would be people bettering on whether a politician/celebrity will wear a certain color at an event. Since these apps allow exactly these sorts of trivial bets, this is not an stretch. That politician/celebrity or their team could easily wear a color that aligns with their bets. This seems indistinguishable from a scam.
> Does JJ really prefer for me to think backwards?
No, you run `jj new` when you’re done with your work just like you’d run `git commit`. You can even just run `jj commit` which is a shorthand for `jj describe && jj new`.
reply