TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Jujutsu Megamerges and jj Absorb

82 点作者 chriskrycho5 个月前

11 条评论

Valodim5 个月前
So interestingly, many folks I&#x27;ve talked to had a reaction of &quot;so jj is just a frontend to git, big whoop. There are hundreds of them, my favorite is X&quot;. That&#x27;s an understandable reaction.<p>But jj is more than that, and you couldn&#x27;t implement it as a git wrapper. I think the core innovation is that rebases are so fast they are essentially free, which opens up amazing potential.<p>But so far I haven&#x27;t found a way to really convey the full weight of this without a long explanation, because people are so used to thinking in git, it takes a long time to go beyond &quot;so rebase -i will be faster, then? But it&#x27;s not slow, is it?&quot;<p>It&#x27;s funny, that git is now in the position that subversion was in almost two decades ago: People were so used to svn and felt productive with it, it was hard to convey why free branches and a distributed data model are a gamechanger, and how much svn limited their thinking. But as a git user you had certainty that you were right, and that your tool is superior.<p>Now, people are so used to git, in an eerily similar way. But ask most git users, &quot;how would you move a specific change from your branch to another?&quot; I have yet to receive a confident answer and workflow to this (they do exist ofc), the common reaction I get is that this isn&#x27;t something they&#x27;d ever need anyways.<p>I&#x27;m curious how this will look in a few years :)
评论 #42508195 未加载
评论 #42508181 未加载
评论 #42508193 未加载
setheron5 个月前
You&#x27;ve been so welcoming in the jj community. Thank you.<p>I don&#x27;t understand how absorb works in your example. Why would the commit &quot;z&quot; be affiliated with some random documentation changes you come across and fix in the wip commit.<p>All that I see is it makes it easier to make small refinements to preciously altered lines ?<p>Super excited for jj.... Almost want to find a work opportunity to promote it. Been a refreshing tool I&#x27;ve adopted in 2024 I&#x27;m happy about.
评论 #42508050 未加载
xyzsparetimexyz5 个月前
This does halfway convince me to try it using jujitsu.. However I think the biggest barrier so far is that I understand how to undo mistakes in git but I don&#x27;t in jujitsu.. if you accidentally run &#x27;jj squash --into x --keep-emptied&#x27; when you meant &#x27;jj squash --into n --keep-emptied&#x27;, how do you undo that?
评论 #42506597 未加载
评论 #42508043 未加载
bjackman5 个月前
I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work:<p>1. Work on smaller projects with simple histories. Git is perfectly satisfactory.<p>2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel).<p>jj is only interesting for part 2, but then it&#x27;s only useful if it&#x27;s easy to bridge into the Git world that everyone else uses.<p>But this workflow is exactly the kind of thing that seems handy. There&#x27;s so much stuff that Git can totally _do_ but could just do a lot _better_.
评论 #42508029 未加载
评论 #42509519 未加载
evgpbfhnr5 个月前
How does jj handle very large git repos, e.g. this linux clone with a mix&amp;mash of quite a few upstreams with a 6GB big .git dir?<p>(I agree I probably shouldn&#x27;t focus on that first, and could just try jj first on smaller rpos... But git is already slow enough in there that it&#x27;s an honest question, I don&#x27;t need to keep using git there as long as I can keep pulling from stable kernels git trees for regular merges)
评论 #42508797 未加载
dilap5 个月前
Looks amazing -- hopefully some day they&#x27;ll add git-lfs support and I&#x27;ll finally be able to try it. :-)
CT4u87985 个月前
Goddammit. This gets me every-time. Click these threads expecting Jujitsu only to find source control!
IshKebab5 个月前
Does jj do anything about submodules being horribly buggy in Git, or LFS being taped on the side as an afterthought? I guess they can fix the submodule bugs but presumably they can&#x27;t fix LFS without breaking Git compatibility?
评论 #42509260 未加载
sausagefeet5 个月前
jj might be the future. I certainly hope git is not. My current system is Mercurial with hg-git and evolve, and so far I find this to be fantastic for local development. There are a few rough edges but I just find hg so simple to use and consistent in functionality. I can usually just figure out how to do what I want from the --help screens. In git I often read the man page for a commit and then I just ask ChatGPT how to do it because the man page for each sub command is a novel. I hope that jj will aim for simplicity in the long run but I guess we&#x27;ll see.
sa15 个月前
There’s also gitbutler for this kind of workflow, a bit more visual.
评论 #42510914 未加载
kkfx5 个月前
It&#x27;s a bit a joke, but not too much: the next step will be full integration with editor&#x27;s undo&#x2F;redo mechanism, which in the end could be seen as a log-based storage. Because that&#x27;s the trend I&#x27;ve seen on the (little) new ideas from the VCS world.
评论 #42512620 未加载