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 :)
I see a future in jj
171–180 of 336 posts
Re: I see a future in jj
#172Re: I see a future in jj
#173As 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
#174I 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…
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
#175Earlier 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.
Re: I see a future in jj
#176Earlier 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.
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
#177I 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…
Re: I see a future in jj
#178I 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…
Re: I see a future in jj
#179I think the real news is that some people have started to build what might become something like a "jjhub" . https://ersc.io/
Re: I see a future in jj
#180> 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'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.