At least for Microsoft, having an AI voice reading from script would likely be an upgrade. I’ve called Windows support a couple times, and half of the time the Indian accent on the other side was so thick I couldn’t understand a thing (and the 4kbps audio quality and call center noise didn’t help either).
I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.
In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.
> For people like me who stage/commit often and judiciously
Focus on judiciously: mostly (functionally) atomic commits that are not every tiny change, not largely meaningless time-based snapshots, not Gerrit-style single commits for entire features, etc. I’m well aware of the mental leap you’re talking about, it’s neither hard to understand nor the liberation you might think it is. To achieve what we want to achieve we either need to be able to split, or “commit” with such atomicity that more time is wasted come squash time.* If you don’t get that, totally fine, but then you just don’t belong very much to this very conversation.
I see your point, but this feels like a difference in workflow philosophy, especially with AI-assisted coding becoming more common.
With jj, your working copy is always a commit. This encourages a "commit often and messy, clean up later" approach. You can rapidly iterate with or without AI, letting jj automatically save every change without stopping to craft perfect atomic commits.
Later, you use a simple jj squash to combine all those small, iterative changes into logical, clean commits before you share it. The atomicity is created retroactively, not upfront. For a finely-tuned magit workflow this might feel wrong, but for rapid, exploratory and AI-driven iteration, it's a more natural fit.
With AI there’s even more reason to have ergonomic splitting if you care about quality commits, since unless you always write the perfect focused prompt, AI can over-generate for the scope of a single commit, so sooner or later you need to split that commit during the cleanup process you mentioned.
I’m using jj for almost a year now and I definitely feel much happier whenever I need to rebase a branch or do an octopus merge. It really is liberating in an incremental way that creeps on you in day to day work. Don’t expect a revolution, though.
Small commits are the same small commits in jj as in git, you just split instead of add -p.
What does the magit interface for staging look like? I only used GUIs were you select the lines with the cursor or mouse and stage that. Is it like that or more sophisticated? Does it support editing hunks better, because that's a thing I only do on the commandline, because my Git GUI doesn't support that.
In magit, the diff is splitted into sections: Untracked, Unstaged and Stage. The sublevels are files then hunks. You can stage and unstage hunks, files and whole section by pressing s and u. Pressing k discards the node (section, file, or hunk.
You can also stage or unstage lines by selecting them first and press the relevan keys.
If you press ‘return’ on a hunk, it brings you directly the the line to edit.
jj wouldn't have any issues with supporting this workflow, if you could replace magit's git commands with some jj ones it'd probably just work. IOW the only thing that's missing is elbow grease.
actually, with jj's seamless rebases, it'd work exactly as you'd want it to (but maybe not how you'd expect if you're used to the git way) when aimed at a commit in the middle of a branch: pick lines which stay below, above or in the middle commit, which you can edit transparently.
The thing is that magit have a lot of commands that makes rebasing a breeze. Pressing c, then s, will allow you to select interactively (from the commits log) a commit to target when doing autosquash. That will create a new commit with the relevant message. Pressing c, the S (shift+s), will rebase immediately, squashing the current staging area into the selected commit.
Interactive rebasing is a breeze. Editing commits is very fast (reordering, dropping rewording, splitting,…). Same with dealing with merge conflicts (Emacs have various merge packages builtin).
The same speed Vim brings to editing, that’s nearly the same speed you get with magit for git.
> Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.
Does not sound any easier or more intuitive than git.
It isn’t how git porcelain wants you to work, but it does make sense once you stop thinking in git. Working copy being a first class commit unlocks all the dag manipulation tools without stashing, having to resolve conflicts in middle of tricky operations, etc. ‘Easier’ is exactly the point, but it’s about workflows which are very inconvenient in git like rebasing stacked PRs.
I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros.
I’ve never used magit but I used GitUp (https://gitup.co/) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be customized.
There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.
And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?
jj doesn’t support it in the sense that there’s no special index feature. You can use a workflow where you have a commit represent the index (and that’s basically the most common workflow). This means you don’t need a separate feature, you just use the tools that slice and dice any commit with your “index”.
As an stgit user, this seems like a weird workflow to me. I never want to have that many uncommitted changes just floating around that will eventually belong to multiple commits. If I'm halfway through something and realise "oh, it would be good to do xyz first" I don't want to have xyz's changes and my half-way-through changes all mixed up -- I want to pop the half-way-through stuff, do the xyz stuff and commit it, then re-push the half-way-through stuff to keep working. If I'm looking at a diff and picking out parts of it then I've done something wrong -- I have a tool for doing it but I only need to use it every couple of months...
I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.
This sort of flow is very nice in jj, primarily because of the “no index” plus “auto commit” behavior, I’ll regularly go “oh yeah I want to go do that” and I’m about to just go do it and then come back to right where I left off, since my work is already saved.
Yeah, I get the impression jj is good for this, and if I were using raw git then it would be a massive upgrade. Luckily for me stgit already does what I want in this area so I have no strong need to investigate alternatives, but if stgit ever bitrots then jj might be a useful next thing.
StGit maintainer here. I have been a jj user for over a year now. It has proven superior to StGit for all of my workloads. I even use jj when maintaining StGit.
An incomplete list of wins vs StGit includes:
- jj makes managing multiple branches fluid, whereas stg has limited tools for managing patches between stacks. 'stg pick' is largely all there is. It's a real dance to move a patch between stacks.
- jj has a much better system for naming changes. I'm super jealous of how jj solved this problem. StGit requires you to name the patches. I added the feature that allows StGit to refer to patches by relative or absolute index in addition to by name. jj's immutable change ids that can be referenced by unambiguous prefix is the correct answer to this problem.
- 'jj rebase' is so vastly superior to stg push/pop/sink/float for reordering changes that I don't even know where to start. It wasn't immediately obvious to me just how flexible, simple, and powerful 'jj rebase' is when I first started using jj, I have learned that it is in its own league relative to StGit's stack ordering story.
- Similarly 'jj squash' makes 'stg squash' look amateurish.
I could go on. If you're a StGit user, you owe it to yourself to give jj a proper try.
On that first point, there's a use case I sometimes have where stgit feels very clunky:
* I have a branch foo with a stack of patches which are the thing I'm working on, based on a master branch
* I have a separate stack of patches on a branch bar (let's say this is a feature that interacts with foo but it's not ready to upstream yet or maybe at all)
* I want to test and work on the combination of foo and bar and make changes that might need to be updates to some patch in foo, or to some patch in bar
At the moment I pick all the patches in foo onto bar in order to do the work and updates in this combined branch, squashing fixes and changes into appropriate patches. Then once I'm happy I go back to the foo branch, blow away the old patches and re-pick them off my combined branch.
This works but feels super clunky -- does jj do better here? That would be a real incentive to try it out.
For the rest, they don't sound like they're strong enough to beat "I've used stgit for 10 years and have a solid workflow with it".
And I just scanned the jj rebase docs and it looks awful, everything I moved to stgit to get away from. I do not want to think about managing a patch stack in terms of "move a bunch of revisions to a different parent". I like having a straightforward stack of patches that I can push, pop and reorder and list. Don't make me think about graphs of commits and multiple rebase suboptions and all that for something that I do all the time in my main workflow, please.
Combined with jj absorb, some people just work this way all the time, even.
> I like having a straightforward stack of patches that I can push, pop and reorder and list.
You can work this way too, what you'd want is `jj rebase` with -A, -B, and -r: r for the revision, and A and B for the before and after you want to move it too. This lets you reorder things however you want pretty straightforwardly. I tend to work in a stack of patches too, or at least, way more than I used to.
What I mean is that I do not want a single "swiss army knife" rebase command that does everything with lots of options to remember. It's fine to have that in the toolbox for the once in six months weird requirement. But for the simple cases I do every day I want simple commands that each do one thing and have memorable names.
If I'm understanding you correctly, you can have both. If there are specific rebase types that you perform regularly, you can create aliases for them and give them whatever name is meaningful to you.
For example, I frequently use `jj up` to rebase the current branch on main. Likewise, `jj pop` rebases just the current commit (popping it from its current place). I even have a `jj ppop` - better name suggestions are welcome - which does this but for the parent commit.
I suspect that the once-off effort to write your own commands would take no longer than it would take to read the documentation if the commands already existed, but with the hopeful extra benefit of giving you a better understanding of how to use rebase for those once in six months weird requirements when they may arise.
But to be clear, I'm not suggesting you must or even should put in this effort if you have something that works for you. My reply is mostly so that anyone who comes across this discussion and sees Steve's mention of -A, -B, etc isn't scared off by them. Whilst they're always there for you, you can use the power it gives you but in the form of single function commands that don't require you to think.
---
For anyone wondering, the aliases I mentioned. These can be dropped in your jj config with `jj config edit --user`.
Most of the time in jj you don’t even rebase manually, because it’s automatic. And the vast majority of the time, I’m using one or two flags to rebase if I am calling it. You might even need only two in this case (before only might be fine?) I just use both before and after because it’s so easy to remember the names.
Anyway you should use the tools you like, it’s all good.
Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...
But there are dozens of great UXs on top of Git already, so if that's 95% of what jj is about then you seem to be making an argument for jj adding very little value. My understanding is that jj offers more than just UX enhancements.
Interesting, isn't it? There you are, and yet none of those dozens are garnering anywhere near the same amount of attention and enthusiasm as jj. And yet, it's genuinely mostly just that -- a novel CLI on top of the same storage backend as git. Sometimes it doesn't take that much to bring about a paradigm shift, I suppose. Just a few new ideas with a great implementation, and there you are -- they've just got to be the right new ideas. That being the hard part.
Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.
This does not compute, like at all. jj rebase is half the reason to use it at all. Everything git does with the commit dag, jj does the same at worst, sometimes better.
It actually sounds like you're confusing jj with something else.
If you open your favorite git editor in a jj repo, everything you stage will become a new commit, everything you revert will… revert. I still use Sublime Merge rather frequently.
I had a recruiter reach out for a company doing Agentic SRE's due to my years of experience as an SRE. Second sentence was describing their mission as making the SRE role no longer necessary for companies. I know if you read between the lines that's the goal of many AI companies, but I was surprised how upfront they were.
There's no reason to hide it anymore. A CEO can go on CNBC and openly admit "Yes, we are excited about AI because if it works we won't have to pay so many middle class white collar workers anymore" and there are many average people who will ideologically defend it, as if they'll somehow be immune.
Any time you dare to mention AI is going to replace software devs here, loads of people come out of the woodwork saying there’s zero evidence and it’s all just the end of ZIRP or whatever.
Well I know for a fact that my company’s art spending is way down, and while we haven’t fired any software engineer we also haven’t added any. I’m very conservative about the AI hype but I can’t deny a 20%-30% boost at the moment so I’m not gonna hire a junior to do the boring 25% for me, who incidentally would be more annoying to steer the way I want. And it wouldn’t surprise me if a slightly more capable model actually makes us slash headcount or at least never need a junior again, same way artists are going. It’s also likely that solopreneurs won’t need to hire in the first place, or will be able to run very lean teams a lot more easily. Many of us will be replaced sooner or later, no idea when, but burying head in the sand doesn’t help much.
Software development jobs will be some of the first to go.
If you think about what we do, it's very manual. We're the assembly line workers of the office. We manualy, painstakingly, put the product together out of primitive pieces.
I recently browsed engineering job ads at x.ai where they looked for experienced software developers as data labelers for about 60 bucks / hour - so they work on replacing their own profession for a low pay. Funny times.
Ironic considering that U.S. does long arm enforcement all the time, often successfully. You can often read stories about U.S. seizing random foreign websites, bitcoins and shit on this very forum. I guess the part where Britain looks “very silly” is that UK’s long arm is much more likely to be ignored than US’s long arm since British Empire’s sun has set?
> as if we haven’t yet shucked-off the American Revolution, let alone colonialism.
I had payment issues with Hetzner too, that was back in 2018, haven’t used them since. At least back then, and at least for me, they were unlike any other provider I’ve used which would send you plenty of warnings if they fail to bill you. The very first email I got from them that smelt of trouble was “Cancellation of Contract”, at which point my account was closed and I could only pay by international bank wire. (Yes I just checked all my correspondence with them to make sure I’m not smearing them.) Amusingly they did send payment warning after account closure. Why not before? No effing clue. That was some crazy shit.
Yes, just because a popular blog about a infamously insecure operating system shrugged off certain classes of security problems as “you’re holding it wrong” two decades ago, OS security should be held to the same standard as that piece of shit OS forever. Nothing to see here.
Edit: IIRC the original argument was more reasonable, but it has since been abused in all kinds of situations to make low effort putdowns, like this one.
To supplement the parent, this is straight from article’s TLDR (emphasis mine):
> In June 2025, I found a critical vulnerability in GitHub Copilot Chat (CVSS 9.6) that allowed silent exfiltration of secrets and source code from private repos, and gave me full control over Copilot’s responses, including suggesting malicious code or links.
> The attack combined a novel CSP bypass using GitHub’s own infrastructure with remote prompt injection. I reported it via HackerOne, and GitHub fixed it by disabling image rendering in Copilot Chat completely.
And parent is clearly responding to gp’s incorrect claims that “…without disclosing how they fixed it. Surely you could just do the base64 thing to an image url of your choice?” I’m sure there will be more attacks discovered in the future but gp is plain wrong on these points.
If you did so too, you would've read the message from github which says "...disallow usage of camo to disclose sensitive victim user content"
Now why on earth would I take all the effort to come up with a new way of fooling this stupid AI only to give it away on HN? Would you? I don't have a premium account, nor will I ever pay microsoft a single penny. If you actually want something you can try for yourself, go find someone else to do it.
Just to make it clear for you, I was musing on the chord of being able to write out the steps to exploitation in plain english. Since the dawn programming languages, it has been a pie-in-the-sky idea to write a program in natural language. Combine that with computing on the server end of some major SaaS(s) and you can bet people will find clever ways to circumvent safety measures. They had it coming and the whack-a-mole game is on. Case in point TFA.
> If you did so too, you would've read the message from github which says "...disallow usage of camo to disclose sensitive victim user content"
They use "camo" to proxy all image urls, but they in fact did remove the rendering of all inline images in markdown, removing the ability to exfil data using images.
> Now why on earth would I take all the effort to come up with a new way of fooling this stupid AI only to give it away on HN?
You just didn't make it very clear that you discovered some other unknown technique to exfil data. Might I encourage you to report what you found to Github?
Because we know exactly what you did and the whole copilot team is laughing at you now! The base64 encoded source code you md5 hashed into our mainframe, you know what you did there is no denying it now. You are on thin ice buddy!
Honestly, this is extremely basic stuff in hosting, not only due to safe browsing, but also—and more importantly—cookie safety, etc. If a hosting provider didn’t know (already bad enough) and turn to whining after being hit, then
> Static site hosting you can trust
is more like amateur hour static site hosting you can’t trust. Sorry.
The thing is, you cannot just add any domain to the PSL. You need a significant amount of users before they will include your domain. Before recently, there really was no point in even submitting, since the domain would have been rejected as too small. An increase in user base, increase in malicious content and the ability to add your domain to the PSL all happen sort of simultaneously.
I'm also trusting my users to not expose their cookies for the whole *.statichost.eu domain. And all "production" sites use a custom domain anyway, which avoids all of this anyway.
There are well-documented solutions to this that don't rely on the PSL. Choosing to ignore all of that advice while hosting user content is a very irresponsible choice, at best.
So the problem here is that Alice on alice.statichost.page might set a cookie for the `.statichost.page` domain if she's careless (which is sometimes the case with Alice). This cookie can then be read by Mallory on mallory.statichost.eu. Or the other way around, if Mallory wants to try to trick Alice into reading his cookie. How this can be prevented without the PSL is something I'm very interested to hear more about.
> it would not have been possible to source local candidates, handle HR and payroll, understand local regulations, etc, without outside assistance
I have no dog in this fight, but I agree with the "smear campaign" that this is 100% bullshit. I work for a fully remote company with employees from all over the world, including Eastern Europe, and we didn't need to partner with any local company, let alone a competitor. Plus even if we need local HR assistance there are plenty of global/local HR services to choose from that focus on HR, no "employee sharing" needed.
I don't know if any other claims are false, but this kind of bullshit obvious to anyone who has been in a similar position undermines everything else they claim. Plus it was never mentioned what these "local partners" get in return, which seems to be the most interesting thing if there's no secret ownership, which is the thing they set out to debunk.
> I work for a fully remote company with employees from all over the world, including Eastern Europe, and we didn't need to partner with any local company
Because your company already has considerable experience in working remotely in another territory, of course they didn't need any help. Or potentially, they were already contracting a firm for local bureaucratic matters.
> Plus it was never mentioned what these "local partners" get in return
Money? They could sell these bureaucratic services at a markup, where they have experience with the paperwork etc. part of expanding internationally.
Additionally, another commenter said they offloaded some worse talent on them[1], so that's another possible benefit to them.
> Because your company already has considerable experience in working remotely in another territory, of course they didn't need any help.
What are you talking about, my company was fully remote with global employees from day one. And no, our CEO/CFO haven’t founded or worked for another fully remote company before that. This is not a radical concept at all, especially not here on HN.
A company operating fully remote with global employees still has to do some bureaucratic work with the countries of their employees for payroll purposes. That's what I meant by the experience they had with this.
reply