Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I see a future in jj

steveklabnik.com

Post reply on HN
Print view View original

211–220 of 336 posts

Re: I see a future in jj

#211

Post by 1718627440 »

aardvark179 wrote: post #175
chrchr wrote: post #164

Earlier quoted context omitted.

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.

Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.

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?

Re: I see a future in jj

#212

Post by miki123211 »

jtwaleson wrote: post #173

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that…

It's important that jj (the local VCS) is fully compatible with Git (the protocol / interoperability standard).

I think this is JJ's biggest advantage. Whether you use it is independent of whether anybody on your team uses it.

Re: I see a future in jj

#213

Post by CGamesPlay »

jtwaleson wrote: post #173

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that…

I started using git when my employer still used svn. This was possible because `git-svn` was so good and it seamlessly allowed me to use branches to do development while still committing to svn's trunk. I think jj is trying to do something similar: jj-unaware tools work reasonably well in colocated jj repositories, and jj-unaware peers (CI tools, etc) work exactly as they did before.

I do agree that you can't really use jj without also knowing "a fair amount" about git, but notably you never need to use the git cli to be an effective contributor to a github project, which is basically the same as `git-svn` was back before git got popular.

Re: I see a future in jj

#214

Post by Hasnep »

jjmarr wrote: post #150

I'm kind of ambivalent about jujutsu. There's too big of an impedance mismatch between GitHub PRs and jujutsu, nor does it have a good VS Code UI. I only use it when I have a ton of minor PRs I want to work on simultaneously, otherwise I just do git worktrees. I'm mainly in favour because my name is JJ and sharing my name with a widely-used source control tool might help my career.

I've been enjoying the jujutsu kaisen VSCode extension, you just need to disable VSCode's built in git integration for each project where you use jj (although I'm planning to invert by disabling git globally and then only enable it for the few projects where I don't use jj)

Re: I see a future in jj

#215

Post by 1718627440 »

Pet_Ant wrote: post #72

One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.

That's called a merge commit. You can even group them further by creating merges of merge commit. It requires you to merge in the right direction though.

Re: I see a future in jj

#216

Post by 1718627440 »

KingMob wrote: post #194
vivzkestrel wrote: post #172

stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?

There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult…

How does JJ ensure that there are now change ID conflicts on push, i.e. so that no two repos generate the same change-id?

Re: I see a future in jj

#217

Post by 1718627440 »

KingMob wrote: post #194
vivzkestrel wrote: post #172

stupid question: can someone with a deeper understand kindly explain, why are talks lurking around the corner about hopping version control systems, whats wrong with git that jj solves?

There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult…

> There's no need for staging or stashes in jj.

What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this, you don't need to use it, these features are purely additive.

Re: I see a future in jj

#218

Post by louistsi »

jtwaleson wrote: post #195
ahartmetz wrote: post #178

Earlier quoted context omitted.

In my case, the shoddiness and thoughtlessness of Git's user interface pisses me off so much that I just want it to be replaced. A good tool similar to Git may even explain Git's concepts better than Git or its documentation that likes to discuss "some tree-ish refs".

I do see that, and git is not perfect, not by a long shot. I'd much rather see an evolution of git itself rather than getting more alternatives.

That essentially is what jj is though, given it can be used on git repositories transparently.

Re: I see a future in jj

#219

Post by 1718627440 »

constantius wrote: post #65
jrockway wrote: post #56

Earlier quoted context omitted.

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…

I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything…

git rebase --update-refs

Re: I see a future in jj

#220

Post by oefrha »

xintron wrote: post #202
oefrha wrote: post #193

Earlier quoted context omitted.

> 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…

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 t…

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.
Post reply on HN