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

161–170 of 336 posts

Re: I see a future in jj

#161

Post by antonchekhov »

steveklabnik wrote: post #82
davidkunz wrote: post #80

Earlier quoted context omitted.

What I would love: - Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation

Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.

I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly + to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.

Re: I see a future in jj

#162

Post by zZorgz »

steveklabnik wrote: post #14
jimbokun wrote: post #8

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

Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both.

If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)

That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).

Re: I see a future in jj

#163

Post by steveklabnik »

zZorgz wrote: post #162
steveklabnik wrote: post #14

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

Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both. If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably a…

Yeah, in that case you may want to configure bookmarks to auto update for sure :)

Re: I see a future in jj

#164

Post by chrchr »

dcre wrote: post #155
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…

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

#165

Post by CGamesPlay »

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…

Seriously! I found that you can still use the git index as long as you don’t run any jj command that changes git_head, and then I made an alias to make a commit from staged changes (squash-index and split-index): https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e...

Re: I see a future in jj

#166

Post by ricericerice »

conradludgate wrote: post #84
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 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

Re: I see a future in jj

#167

Post by surajrmal »

steveklabnik wrote: post #148
martinvonz wrote: post #147

Earlier quoted context omitted.

j2kun seems to be a googler so I don't think so, but it's true that Facebook also went with Mercurial. I suspect it was for similar reasons.

Ahh. It sounded like a repeat of https://graphite.dev/blog/why-facebook-doesnt-use-git but maybe it did happen for both companies! They’d obviously be having similar issues. Thanks :)

I can second that the aforementioned reasons are true. The funny difference is that Google employs the primary git maintainer. Git has a lot of customers though so it rightfully is very conservative with development.

Re: I see a future in jj

#168

Post by zZorgz »

steveklabnik wrote: post #163
zZorgz wrote: post #162

Earlier quoted context omitted.

Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both. If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably a…

Yeah, in that case you may want to configure bookmarks to auto update for sure :)

Is there a way to do that today?

For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).

It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.

Re: I see a future in jj

#170

Post by baby »

That's exciting! Have you guys looked into sappling from Meta as well? It looked really cool the last time I looked into it but never tried to use it much.
Post reply on HN