It does some merge magic so that PR B shows the correct diff; and does so without needing to force push, so on your side you can just "git pull" and continue working.
Of course I expect this repo to become obsolete when GitHub makes their native stacking public.
That it's it's better to publish the garbage data than to not publish it though. I would worry about complaining too much lest they just decide to stop publishing it because it creates bad PR.
As long as the garbage data is authentic and the method used to produce it is adequately detailed, I agree with you that: "it's better to publish the garbage data than to not publish it"
But fake data or garbage data without the method, is better left unpublished !
The point is authorization. With full web access, your agent can reach anything and leak anything.
You could restrict where it can go with domain allowlists but that has insufficient granularity. The same URL can serve a legitimate request or exfiltrate data depending on what's in the headers or payload: see https://embracethered.com/blog/posts/2025/claude-abusing-net...
So you need to restrict not only where the agent can reach, but what operations it can perform, with the host controlling credentials and parameters. That brings us to an MCP-like solution.
Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.
Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow.
I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration.
Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over.
jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically.
The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.
Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`
Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.
The problem I have had with this type of app is that, on Instagram at least any video that a friend posts is considered a reel. And I want to watch videos that my friends post. What I don't want is swiping mindlessly through random videos. So really I would like a swipe blocker not a short video blocker. (And bonus points if I could make it work on Firefox)
This is a good point, I will try to find a solution. Currently, it's able to whitelist Reels from the DM feed, and it will block the rest as soon as you start scrolling, I'll see how to do this for normal posted reels.
On the one hand, yes this has obviously high immediate value; on the other hand, I can't help but feel like you are giving access to multiple tools that can be used for arbitrary code execution anyway (i.e. running tests, installing dependencies, or running any linter that has a plugin system...), so blacklisting `git --exec-path=/bin/sh` for example is... Misguided? You would have a better time containing the agent in an environment without internet access?
It’s not misguided. The goal isn’t prefect security, the goal is mitigating risk and collaborating with cross functional security, compliance, platform, operations, etc… teams.
Use Jules, also by Google if you need what you describe.
I have an actual oven where I can select "programs".
As far as I can tell, they control three parameters:
* Where the heat comes from (top, bottom, or both)
* Whether or not ventilation is activated
* The temperature
There is also a dial for temperature, but not for the other two parameters. I am not sure whether every combination is covered by the "program" dial. I am not sure whether or not my understanding is even correct.
I would say it's an 7.5 out of 10 on the nightmare bicycle scale.
Settings like "Bake", "Roast", etc are quite frustrating. They do have meanings, but pretty much no user knows what they mean. A selector that lets the user choose which heating elements they want to use might be useful, but this seems like it might be a case where if the user doesn't know the difference between "Bake" and "Roast" they may also not be in a position to decide if they want heat from the bottom, top, or both anyway.
It does some merge magic so that PR B shows the correct diff; and does so without needing to force push, so on your side you can just "git pull" and continue working.
Of course I expect this repo to become obsolete when GitHub makes their native stacking public.
reply