Live data from Hacker News

I see a future in jj

steveklabnik.com

171–180 of 336 posts

Re: I see a future in jj

#171

I think the real news is that some people have started to build what might become something like a "jjhub" . https://ersc.io/

I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)

If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.

Re: I see a future in jj

#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?

Re: I see a future in jj

#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 works with e.g. repo analysis will need to start supporting git and jj. More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere).

Given all the downstream effects, I do not think introducing another VCS is a net positive.

Re: I see a future in jj

#174
post #64

I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review? I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and p…

One thing to note is that the actual commit objects you make through jj do include a `change-id` header which means that even though Github is unaware of jj, peers using jj will still be able to keep track of the rebases.

Demo: run `git cat-file -p HEAD` in any jj repository that you've made a change to.

Re: I see a future in jj

#175
post #164
post #155

Earlier quoted context omitted.

I’m curious what the magit hunk selection UX consists in. I couldn’t find any videos showing something substantially different from the one built into jj — the videos I found were meant as beginner intros. I’ve never used magit but I used GitUp ( https://gitup.co/ ) for years before jj. I don’t find the jj one super natural, but I feel like that’s mostly a matter of keyboard shortcuts — I need to see if they can be c…

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.

Re: I see a future in jj

#176

Earlier quoted context omitted.

What do you mean by this? It's hardly equivalent to LFS. The binary files aren't replaced with a text pointer with actual content stored on a server elsewhere. Binary files are stored in the same place as text files.

From the user's perspective, when setup correctly Git LFS is transparent and they don't see the text pointers - the binary files are replaced on push and pull to the server. It's the same user experience as Perforce? Yes, Git is more low-level and it's possible to see those text pointers if you want to.

This is what you want to believe but its not true.

I’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers.

It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone after the call, and it’s clunky to use and to save.

… but technically the feature exists, so it’s harder to argue for better software thats fit for purpose, like miro or mural.

Re: I see a future in jj

#177
post #130

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For pe…

If you open your favorite git editor in a jj repo, everything you stage will become a new commit, everything you revert will… revert. I still use Sublime Merge rather frequently.

Re: I see a future in jj

#178

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…

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".

Re: I see a future in jj

#180
post #70

> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size. I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing,…

I don't think this is quite right. The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).

I used git5 from when I started in 2011 to when I left in 2017.

I'm going back starting on monday, so I'm curious to try out jj.

In the past 10 years it's all been github and gitlab, and their code review tools are so painful, specifically w.r.t. tracking discussions across revisions. I never felt excited to try out jj because I was afraid it would that situation even worse.

Post reply on HN