I think the real news is that some people have started to build what might become something like a "jjhub".
I see a future in jj
51–60 of 336 posts
Re: I see a future in jj
#52Earlier quoted context omitted.
You're kind of right about LLM knowledge but the implication is funny. We just cant be expected to learn new things without LLMs...
What a terrible world we're barrelling towards when "LLMs don't know about it" is considered a blocker towards something taking off. Read a blog post, read a man page (which GP says was indeed their solution), or just play with the dang tool, I assure you these things are still possible without the assistance of a predictive text engine helping you!
One problem is that Stack Overflow isn’t being updated with questions about new tools because it’s been crowded out by LLMs, so the LLMs can’t train on these nonexistent new questions/answers.
Re: I see a future in jj
#53Earlier quoted context omitted.
So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git.…
can you directly get the parent branch of a branch in jj? This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."
Right, “parent branch” implies a tree structure, but git is a DAG.
You might have a specific workflow such that you can actually answer your question, but it won’t generally apply to all repos.
Since a branch is really just a label for a specific commit, which may be at the end of a chain of successive parent commits, a branch isn’t really a first class structure, but a derived one.
You can get the fork point of a branch, which is a common ancestor commit shared by another branch, but that fork point is a commit and may not have a branch label. That commit can have any number of other branches going off of it: how would you decide which one is the parent vs just another sibling?
My assumption after looking at jj is that it is not as complicated as git yet. Give it time. It’s also not even as simple as git for many tasks, based on their own docs: https://jj-vcs.github.io/jj/latest/git-command-table/
Re: I see a future in jj
#54[flagged]
> There are no substantial technical or usability reasons to switch to JJ from Git
Every magit user disagrees with you.
> and it's impractical for most working programmers to switch
This very much sounds like someone who has never even tried jj. Tell us: What makes switching impractical?
> My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your life in a few years on code that doesn't live up to its promise and is essentially no different than the code that already exists in Git (and Hg, Pijul, Fossil, etc.),
Is Steve even a developer for jj?
Re: I see a future in jj
#55At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted. I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remem…
I learned all of cvs, svn and then later git when getting into Linux and Open Source. Based on my early experience of multiple systems, I'm very surprised that git has dominated and lasted this long already!
Re: I see a future in jj
#56At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted. I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remem…
jj is actually so good though. People don't need to know you're using it, which is why it's nice.
A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all 3 of them together. (Sometimes you want to write the docs / take screenshots as though all your features are merged as-is.) jj makes all this trivial. You tell it what you want and it does it without involving an index or working copy or interrupting you to resolve conflicts.
I've found that it really makes me less annoyed when working with other people. I don't know why it takes people longer to review code (or to even open the review request) than it takes me to write things. But it does, and jj is what keeps me sane.
To be fair, I also use it on personal projects because sometimes you have 3 things you want to try at once and they're not related to each other. Upstream isn't going to change without your understanding, but it's still mechanically something to maintain the rebases on those 3 branches. jj just makes this burden go away.
Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.
Re: I see a future in jj
#57[flagged]
> There are no substantial technical or usability reasons to switch to JJ from Git Every magit user disagrees with you. > and it's impractical for most working programmers to switch This very much sounds like someone who has never even tried jj. Tell us: What makes switching impractical? > My well-intentioned recommendation to Steve, because I've been there, is: If you want to avoid feeling like you've wasted your li…
I have not contributed to jj directly basically at all yet: https://github.com/jj-vcs/jj/commits?author=steveklabnik
I am assuming that this new job will change that.
Re: I see a future in jj
#58Earlier quoted context omitted.
I used to think the same way about jj not too long ago. I even wrote a few comments here similar to yours, but since then I’ve changed my mind. For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back
May I ask what is your rebase workflow at work? In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.
Basically the same except in some projects we are not supposed to squash. So, sometimes we end up with long long histories to be rebased onto other long histories.
rerere only helps so much with conflict resolution but with jj I think it is as painless as it could be.
Re: I see a future in jj
#59Earlier quoted context omitted.
One thing not mentioned in the article: what advantages does jj offer over plain git?
So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git.…
Git's CLI is awful compared to fossil or even mercurial. Jj seems like an improvement over git, but it lacks a web UI like fossil has. It's very useful. Basically like a self contained github lite, only without the needless complexity, the enterprise bs, the annoying login process, tokens, passkeys, brain damaged permissions system etc.
Re: I see a future in jj
#60Earlier quoted context omitted.
can you directly get the parent branch of a branch in jj? This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."
Could you spell out slightly more what you mean? I'm not 100% sure what "get" means.
I think they mean what other branch some branch was originally branched off from.