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

181–190 of 336 posts

Re: I see a future in jj

#181

Post by conradludgate »

ricericerice wrote: post #166
conradludgate wrote: post #84

Earlier quoted context omitted.

I use git but I instead just keep all PRs stacked on top of each other and rebase when one is merged. If something is easy to review I push it down the stack. If something is harder to review I keep it at the top of the stack. I don't open a PR for each commit, and we use squash commits at work which makes it harder to have this workflow but it still works fine for me. I rebase only the leaf PR, and I have update-ref…

i believe `jj fix` is your -x equivalent, though im not familiar enough with it to comment on how similar the semantics actually are

It is not even close to sufficient. jj fix only executes the command on one file at a time (only the changed files) so it can't work on anything that has linter semantics.

jj does this for performance reasons. They don't want to perform a full checkout for every rebase action. This is simply something I disagree with

Re: I see a future in jj

#182

Post by ivolimmen »

jonstewart wrote: post #112

What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a…

PR's are a man made ritual that was never required by GIT. Just like we are all doing the Lean/Scrum or whatever dance. It does not change the development process, it's just a man made ritual for collaboration. The branching model is nicer to work with than the revision based model from subversion though.

Re: I see a future in jj

#183

Post by ivolimmen »

steveklabnik wrote: post #137
RustSupremacist wrote: post #132

This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results. I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.

I certainly don’t think anything is a sure thing.

Death and taxes though...

Re: I see a future in jj

#184

Post by KingMob »

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…

Having used jj for the last year and a half, I hear you on the tooling issues. From IDEs, to plugins, to docs, to workflows, to LLMs, jj is not as well supported as git.

Despite that, it's still a net time-saver for me, and I suspect the same will be true for others. Git imposes constant overhead, mostly with its poor UI, but also by some of its unnecessary models (e.g., staging as a separate concept).

Re: I see a future in jj

#185

Post by martinvonz »

conradludgate wrote: post #181
ricericerice wrote: post #166

Earlier quoted context omitted.

i believe `jj fix` is your -x equivalent, though im not familiar enough with it to comment on how similar the semantics actually are

It is not even close to sufficient. jj fix only executes the command on one file at a time (only the changed files) so it can't work on anything that has linter semantics. jj does this for performance reasons. They don't want to perform a full checkout for every rebase action. This is simply something I disagree with

> jj does this for performance reasons. They don't want to perform a full checkout for every rebase action.

It's true that `jj fix` can be faster by not touching the working copy, but we also want a `jj run` command for the linter feature (https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.

Re: I see a future in jj

#186

Post by baq »

dagenix wrote: post #99
baq wrote: post #24

I’m just sad pijul doesn’t get the same attention or love from the community. It desperately needs an ability to colocate with git.

I strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.

As long as some repository state in either system can map onto a checkout in the other system it should be possible at least in some capacity. I’d like to try out pijul at work, but I’d need an analog of jj git fetch and jj git push. Whatever happens in between doesn’t really matter too much unless it’s tedious manual bookkeeping to maintain history mapping.

Re: I see a future in jj

#187

Post by PhilippGille »

bitbasher wrote: post #158
weinzierl wrote: post #51

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

This is a great thing and I'm hoping for its success. It's about time we have a real alternative to Github.

What makes GitLab not a real alternative?

Re: I see a future in jj

#188

Post by Zambyte »

benhurmarcel wrote: post #83
weinzierl wrote: post #51

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

There’s this as well: https://blog.tangled.org/stacking

I personally find this to be more interesting simply because it has the social inertia of Bluesky behind it. Software has centralized on GitHub because it is discoverable there. Software on Tangled is discoverable through Bluesky, and the stacking support to make jj nice to use with it is just an added bonus.

Re: I see a future in jj

#189

Post by baq »

oefrha wrote: 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…

In jj you aren’t supposed to be even thinking about staging and committing, that’s the mental leap required to get what the fuss is about. Everything is a change and you bookmark a parent (or something further out) as the branch head into which you squash or advance the bookmark to a next ready change.

Re: I see a future in jj

#190

Post by wutbrodo »

diegs wrote: post #180
joshuamorton wrote: post #123

Earlier quoted context omitted.

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.

It was deprecated in 2015 iirc
Post reply on HN