<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: saghm</title><link>https://news.ycombinator.com/user?id=saghm</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Tue, 14 Apr 2026 17:14:13 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=saghm" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>In a pure `jj` model, commit might not even be necessary as it's own subcommand (since you could easily define an alias for `desc` followed by `new`). We're still living in a world where most people who would consider adopting `jj` are git users currently, so I wonder if starting with `commit` and then following it up with an explanation of "here's how you can change the commit message without needing to make a new commit" and "here's how you can make a new commit without changing the name of the current one" would end up fitting people's expectations better.</p>
]]></description><pubDate>Tue, 14 Apr 2026 16:15:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=47767589</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47767589</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47767589</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>That's my overall point: the argument itself (with respect to the current state of the repo) is what determines the behavior. I don't think this is anywhere close to as intuitive as commands that only ever accept one "type" of argument (and erroring if it's different).</p>
]]></description><pubDate>Tue, 14 Apr 2026 16:11:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=47767527</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47767527</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47767527</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>> In all 3 cases, the command is pointed at a commit and the behavior is the same<p><pre><code>    echo "something" >> foo.txt
    git checkout foo.txt
</code></pre>
What's the name of the branch this is pointed at? If I have to run another git command to find out, then it's not "pointed" at it.</p>
]]></description><pubDate>Tue, 14 Apr 2026 15:13:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=47766723</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47766723</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47766723</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>I disagree with the people saying "never use edit". There are plenty of people saying conflicting things about git too, and I'd argue that understanding edit versus new isn't anywhere close to the level of wart that having to get people to agree on merging versus rebasing. Like you said though, have fun with that!</p>
]]></description><pubDate>Tue, 14 Apr 2026 15:10:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=47766659</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47766659</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47766659</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>> JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects.<p>The difference is that I can (and do) use `jj` with existing git repos today without needing anyone else using the repo to change what they're doing. There's no need to replace something when it can exist alongside it indefinitely.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:29:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=47766130</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47766130</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47766130</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>I haven't noticed any significant change in my workflow needed to accommodate this, but it might be because I've always used rebase rather than merge. `jj rebase -d main` will put my current branch on top of the main branch, and fixing conflicts in `jj` is a breath of fresh air compared to git.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:25:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=47766072</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47766072</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47766072</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>Are you accessing these boxes via ssh or using them directly? If it's via ssh, I'd expect that you would already be using the clipboard for copying the names of them rather than typing them out manually, at which point copying `git clone <a> && git clone <b> && ...` would achieve the same thing.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:20:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=47766020</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47766020</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47766020</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>How so? I've used `jj` locally on teams where most (if not all) of the other team members were using git, and they only found out I was using `jj` when I told them.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:15:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765954</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765954</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765954</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>It's been over a year since I last used git manually in the CLI, and I've exclusively worked with git remotes. The only time I had any friction was on a team where stale code-gen output was checked into the repo and for whatever reason no one was willing to either add it to the `.gitignore` or commit (pun intended) to keeping it up to date, meaning that I had to manually remove the changes from when I compiled before pushing. I would have argued in favor of adding to .gitignore or keeping it up to date even if I didn't use `jj` though because I think having stale output checked in is just silly.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:13:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765940</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765940</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765940</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>Nothing stops you from doing the equivalent of `git push --force` in `jj`. The flag is just named differently: `--ignore-immutable`. This is a global flag though, so it's available to all commands, and `jj` requires it whenever you're making changes to immutable commits, even locally. I'd argue that this is one of the killer features of `jj`, since by comparison `git rebase` treats everything the same whether you're squashing your own local commits on a feature branch or messing with the history of `main` in a way that would break things for everyone.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:09:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765894</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765894</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765894</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>The idiom here is use `edit` if you want to edit a commit, and use `new` if you want to make a new commit. This works identically whether you specify the commit via branch name or commit id. I'm not sure why people are saying not to use `edit` ever. It's basically just a shorthand for staging and amending changes in an existing commit, and there's still a use case for that; it's just not "I want to see the changes on this old branch".</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:05:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765827</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765827</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765827</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>Using `jj edit` will edit a commit you specify, and `jj new` will make a new empty commit after the one you specify. These work exactly the same whether you specify a commit by branch or by the hash. I'd argue that you're getting exactly what you ask for with these commands, and by comparison, what "checkout" is asking for is much less obvious (and depends on context). We've just internalized the bad behavior of git for so long that it's become normalized.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:02:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765793</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765793</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765793</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>> jj edit is the biggest jj footgun I can think of<p>Honestly, this is only because `git checkout` is so convoluted that we've collectively changed our expectations around the UX. "checkout" can mean switching to another branch (and creating it if you specify a flag but erroring if you don't), looking at a commit (in which case you have "detached HEAD" and can't actually make changes until you make a branch) or resetting a file to the current state of HEAD (and mercy on your soul if you happen to name a branch the same as one of your files). Instead of having potentially wildly different behavior based on the "type" of the thing you pass to it, `jj edit` only accepts one type: the commit you want to edit. A branch (or "bookmark", as jj seems to call it now) is another way of specifying the commit you want to edit, but it's still saying "edit the commit" and not "edit the bookmark". Unfortunately, the expectation for a lot of people seems to be that "edit" should have the same convoluted behavior as git, and I'm not sure how to bridge that gap without giving up part of what makes jj nice in the first place.</p>
]]></description><pubDate>Tue, 14 Apr 2026 13:58:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765751</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765751</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765751</guid></item><item><title><![CDATA[New comment by saghm in "What is jj and why should I care?"]]></title><description><![CDATA[
<p>How are you "checking out" the old commit? It sounds like you're using `jj edit`, which I'd argue does what it says on the tin. Switch to using `jj new <branch>` and your problem goes away.</p>
]]></description><pubDate>Tue, 14 Apr 2026 13:40:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765527</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765527</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765527</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>I often will use `jj new -B@` (which I made an alias for) followed by `jj squash -i` to split changes. I had no idea about `jj split`, so I need look into that!</p>
]]></description><pubDate>Tue, 14 Apr 2026 13:38:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765510</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765510</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765510</guid></item><item><title><![CDATA[New comment by saghm in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>Nothing stops you from making changes in a commit that has no description and then at the end doing `jj commit -m` to describe them and make a new commit in one go, which is essentially the same as git. The difference is that it's essentially amending in place as you make changes rather than needing to stage first.</p>
]]></description><pubDate>Tue, 14 Apr 2026 13:36:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=47765491</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47765491</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47765491</guid></item><item><title><![CDATA[New comment by saghm in "GitHub Stacked PRs"]]></title><description><![CDATA[
<p>Their point was that by offloading the bottlenecks to C, you've essentially conceded that Python isn't fast enough for them, which was the original point made above</p>
]]></description><pubDate>Tue, 14 Apr 2026 05:46:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=47761716</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47761716</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47761716</guid></item><item><title><![CDATA[New comment by saghm in "GitHub Stacked PRs"]]></title><description><![CDATA[
<p>> You could reimplement it in Python and I doubt it would see any significant slowness<p>I doubt it <i>wouldn't</i> be significantly slower. I can't disprove it's possible to do this but it's totally possible for you to prove your claim, so I'd argue that the ball is in your court.</p>
]]></description><pubDate>Tue, 14 Apr 2026 05:44:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=47761702</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47761702</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47761702</guid></item><item><title><![CDATA[New comment by saghm in "Servo is now available on crates.io"]]></title><description><![CDATA[
<p>Interesting, it's certainly possible I was never aware of the super early days.</p>
]]></description><pubDate>Mon, 13 Apr 2026 17:43:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=47755467</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47755467</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47755467</guid></item><item><title><![CDATA[New comment by saghm in "Microsoft isn't removing Copilot from Windows 11, it's just renaming it"]]></title><description><![CDATA[
<p>To be fair, the .NET brand is already super convoluted (there's .NET framework, the .NET core, .NET runtime, the .NET desktop runtime, the .NET sdk, and I'm genuinely not even sure which if any of these might refer to the same thing), on top of it weirdly sounding like something internet related to a casual user.</p>
]]></description><pubDate>Mon, 13 Apr 2026 15:30:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=47753456</link><dc:creator>saghm</dc:creator><comments>https://news.ycombinator.com/item?id=47753456</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47753456</guid></item></channel></rss>