4 ms·

This got spammed a lot but does anyone actually use it in the wild? We have This and Sapling (mercurial) for alternative git. Back in 2014 up til 2018 we used m

by v3ss0n 2y ago

This got spammed a lot but does anyone actually use it in the wild? We have This and Sapling (mercurial) for alternative git. Back in 2014 up til 2018 we used mercurial , development workflow is a lot smoother and better in DX wise vs git but soon after bitbucket decided to cut mercurial we have no choice but to use Git since there is literally no opensource or cloud service mercurial `hub` in existence. What you need for your CVS to be popular is not having a new CVS that do a thing a little bit different and better vs Git but to have a good GitHub alternative. In Git world there we have Gitea - which is very easy to setup and experience is much better than github , and gitlab for bigger orgs. Plus a good IDE support. Sapling and JJ need something like that - built in or selfhostable.

Skinney 2y ago
I'm using it for everything now. The beauty of JJ is that everyone else on my team can keep on using git if they want, even if I'm using JJ on the same repo.
fragmede 2y ago
Given than jj is compatible with git servers, does it matter? If you prefer jj, you can just use it on your laptop to just get shit done, meanwhile using whatever git server you're given.
sbaildon 2y ago
Mitchell of Hashicorp and Ghostty fame uses jj https://x.com/mitchellh/status/1845869748841832667 https://x.com/mitchellh/status/1845869748841832667
MrJohz 2y ago
JJ should be compatible with any existing Git server. The project is currently maintained on Github, and I believe all the maintainers use JJ to work on the project itself. At work, I use JJ a lot with repositories hosted on Azure Devops, and that also works well (in some ways, better than Github). This is using JJ's "Git" backend, which internally stores data as Git refs, and communicates with other servers the same way that Git does. There is a work-in-progress native backend, but this is still being developed and you need to explicitly opt into it if you want to try it out.
steinuil 2y ago
> but to have a good GitHub alternative. JJ doesn't currently have a "native" repository format (or rather, it's in development and not ready for general usage), so right now a JJ forge wouldn't look too different from your usual Git forges. Everybody who's using it right now uses it on Git repos on Git forges. I've been using it for months on my own and at work and I didn't make any changes to the infrastructure outside of my own command line usage. It would be interesting to see what a JJ-native forge would even look like in the future, but I don't think anybody knows exactly what that would be right now! JJ is in development (but stable enough to work with) and people have only just started using it, so it's still in the phase of discovering what workflows are possible. > Plus a good IDE support. Now that's something I would love to see. Git tooling works mostly fine but due to how JJ's git backend works, it always thinks it's in a "detached HEAD" state.
- v3ss0n 2y ago
  i gotta try a bit then.
- gpm 2y ago
  > Everybody who's using it right now uses it on Git repos on Git forges. As I understand it there's also a group of Googlers using it internally at Google with an internal to Google non git backend.
KingMob 2y ago
A year ago, I played around with jj out of curiosity, and within a couple weeks, I was ready to abandon git forever, despite jj still being so new. I only use git directly when I have to now. (As others have pointed out, jj uses git as a storage/network layer, so you don't need a new forge to start using it.)
jrockway 2y ago
I'm using it day to day for my personal projects and at work. The thing that always annoyed me about ... work ... is that I'll be working on like 5 things, with 4 of them being code reviewed at my code reviewer's leisure. So I always end up with a crazy stack of branches, and as "main" changes, the burden of keeping everything up to date becomes painful. jj makes this all very easy! "jj rebase -d main" to clean up one of my topic branches. No interrupt to whatever I'm working on (as git checks out the files to your working copy and you resolve conflicts for each step in "git rebase main"). Conflicts can be removed at your leisure. Something I always regretted doing with my many-topic-branches-out-for-review approach was making changes that depend on two topic branches. With jj, it's easy, you just "jj new qrs xyz" and now you have a new change on top of those two topic branches. If you add something in this commit that you want in one of your topic branches, "jj squash --onto qrs some/change/to/qrs.go" and now that change is in there. It works well with Github and a PR per change. You create a PR with "jj bookmark create whatever" and then "jj git push --allow-new" to make "whatever" a remote branch. As you update that commit, "jj git push" adjusts the remote state as necessary. "jj git fetch" automatically adds bookmarks for upstream branches (so you can "jj new coworker/their-change" to test and modify their thing locally). Finally, it works well when you have persistent changes that you don't want to commit but you do want to keep around. For some reason, we check in dev configs, and each engineer needs to modify them to run stuff locally. I have a commit called 'private: local setup' and that forms the base for each new (local) commit I work on. To do a PR, I squash my changes into a commit based on main instead of that commit. jj will avoid pushing anything with the prefix 'private: ' so I don't have to worry about leaking my keys, even though they are checked in locally. I wouldn't recommend managing secrets like this, but ... I didn't make this decision and jj handles it fine. Overall, a huge improvement to my workflow. There have been times when I have so much stuff in flight that I just give up for the day until a few PRs get resolved. That never happens anymore. I can kind of work on whatever I want and let the world move at its own speed. Updating my work to account for PR comments or PRs merged before mine now takes seconds and never goes wrong. Truly an amazing tool and I wish I discovered this years ago.

by v3ss0n 2y ago

Skinney 2y ago

I'm using it for everything now. The beauty of JJ is that everyone else on my team can keep on using git if they want, even if I'm using JJ on the same repo.

fragmede 2y ago

Given than jj is compatible with git servers, does it matter? If you prefer jj, you can just use it on your laptop to just get shit done, meanwhile using whatever git server you're given.

sbaildon 2y ago

Mitchell of Hashicorp and Ghostty fame uses jj https://x.com/mitchellh/status/1845869748841832667 https://x.com/mitchellh/status/1845869748841832667

MrJohz 2y ago

JJ should be compatible with any existing Git server. The project is currently maintained on Github, and I believe all the maintainers use JJ to work on the project itself. At work, I use JJ a lot with repositories hosted on Azure Devops, and that also works well (in some ways, better than Github). This is using JJ's "Git" backend, which internally stores data as Git refs, and communicates with other servers the same way that Git does. There is a work-in-progress native backend, but this is still being developed and you need to explicitly opt into it if you want to try it out.

steinuil 2y ago

> but to have a good GitHub alternative. JJ doesn't currently have a "native" repository format (or rather, it's in development and not ready for general usage), so right now a JJ forge wouldn't look too different from your usual Git forges. Everybody who's using it right now uses it on Git repos on Git forges. I've been using it for months on my own and at work and I didn't make any changes to the infrastructure outside of my own command line usage. It would be interesting to see what a JJ-native forge would even look like in the future, but I don't think anybody knows exactly what that would be right now! JJ is in development (but stable enough to work with) and people have only just started using it, so it's still in the phase of discovering what workflows are possible. > Plus a good IDE support. Now that's something I would love to see. Git tooling works mostly fine but due to how JJ's git backend works, it always thinks it's in a "detached HEAD" state.

v3ss0n 2y ago
i gotta try a bit then.
gpm 2y ago
> Everybody who's using it right now uses it on Git repos on Git forges. As I understand it there's also a group of Googlers using it internally at Google with an internal to Google non git backend.

KingMob 2y ago

A year ago, I played around with jj out of curiosity, and within a couple weeks, I was ready to abandon git forever, despite jj still being so new. I only use git directly when I have to now. (As others have pointed out, jj uses git as a storage/network layer, so you don't need a new forge to start using it.)

jrockway 2y ago

I'm using it day to day for my personal projects and at work. The thing that always annoyed me about ... work ... is that I'll be working on like 5 things, with 4 of them being code reviewed at my code reviewer's leisure. So I always end up with a crazy stack of branches, and as "main" changes, the burden of keeping everything up to date becomes painful. jj makes this all very easy! "jj rebase -d main" to clean up one of my topic branches. No interrupt to whatever I'm working on (as git checks out the files to your working copy and you resolve conflicts for each step in "git rebase main"). Conflicts can be removed at your leisure. Something I always regretted doing with my many-topic-branches-out-for-review approach was making changes that depend on two topic branches. With jj, it's easy, you just "jj new qrs xyz" and now you have a new change on top of those two topic branches. If you add something in this commit that you want in one of your topic branches, "jj squash --onto qrs some/change/to/qrs.go" and now that change is in there. It works well with Github and a PR per change. You create a PR with "jj bookmark create whatever" and then "jj git push --allow-new" to make "whatever" a remote branch. As you update that commit, "jj git push" adjusts the remote state as necessary. "jj git fetch" automatically adds bookmarks for upstream branches (so you can "jj new coworker/their-change" to test and modify their thing locally). Finally, it works well when you have persistent changes that you don't want to commit but you do want to keep around. For some reason, we check in dev configs, and each engineer needs to modify them to run stuff locally. I have a commit called 'private: local setup' and that forms the base for each new (local) commit I work on. To do a PR, I squash my changes into a commit based on main instead of that commit. jj will avoid pushing anything with the prefix 'private: ' so I don't have to worry about leaking my keys, even though they are checked in locally. I wouldn't recommend managing secrets like this, but ... I didn't make this decision and jj handles it fine. Overall, a huge improvement to my workflow. There have been times when I have so much stuff in flight that I just give up for the day until a few PRs get resolved. That never happens anymore. I can kind of work on whatever I want and let the world move at its own speed. Updating my work to account for PR comments or PRs merged before mine now takes seconds and never goes wrong. Truly an amazing tool and I wish I discovered this years ago.