21–30 of 128 posts
I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…
I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…
Different folks will have different preferences when it comes to adopting new tools. Some like "tried and true", some want to experiment and see what's out there.
I (an avid `jj` user) like to think I want some pragmatic blend: I want tools that help me get my job done, and otherwise get out of the way. So if I think there's room for improvement in my workflows (in this case, managing 10-20 ongoing changes at a given time across 5-6 projects), I'll experiment with new tools that can help reduce the friction for me.
Like you said, there's functionally nothing `jj` can do that `git` can't, Jujutsu literally uses git as the default backend. For me, the power of Jujutsu is the massively reduced cognitive overhead of using it. My thoughts more directly translate to `jj` commands and I rarely have to think about it, even with complex stacks of changes.
I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…
I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60…
Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a mess of wrong abstractions.
And unfortunately, these days I'm back using git with the rest of the world. Can't wait for the day when Jetbrains gets a good plugin for either `jj` or `sapling`, and I never have to google another git command again ...
I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…
The thing about jj is that it doesn't actually enable any new capabilities . I tell people to use emacs or vim or vscode or whatever instead of notepad because it gives them new capabilities , things that are simply unavailable unless you're talking to an LSP or running a full-powered scripting engine. jj doesn't make anything possible the way going from notepad to a real editor does. What jj does do is it makes ever…
[1] the top testimonial on https://jj-vcs.github.io/jj/latest/testimonials/ is mine
how does it work the other way? if i’m using jj, and my colleagues are using git, how does it cope? in particular what if they are using git in a really depraved way (like just add all files and always commit everything, etc.)?
I have used jj for about one month on a project with a colocated git repo. So far, I enjoy it a lot. Previously I would have a bunch of 'wip', 'fix typo' commits, but my commit history got much cleaner with jj. It's very easy to jump to old changes and apply fixes right in the place they belong. All changes + tests are now committed as one unit. I would never bother to do it in git, but because it's so easy now, I do…
[ui.movement]
edit = true
it’s great that jj just looks like you use git to other people, so doesn’t inconvenience them. how does it work the other way? if i’m using jj, and my colleagues are using git, how does it cope? in particular what if they are using git in a really depraved way (like just add all files and always commit everything, etc.)?
You're both operating on git repositories, so there's no issues. You can think of jj as an alternate git client.
How can I not constantly fight jj with this?
I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…
Not to mention the rainbow colors are a bit of a turnoff. I like a little color here and there, but not ransom-note style. Monochrome effects are available folks.
What workflow do people adopt for tools which still do not have a concept of local-only config files? For example, VSCode only has a launch.json, which should be committed, but I might need to customize it to my environment/current problem without distributing those edits. How can I not constantly fight jj with this?
Basically, just have a local-only merge-change that combines whatever you're working on, with all your local modifications. You can then even just create new changes on top of the `` change, and then rebase each into your branch when you're done with it, for even better ease-of-use (using `jj rebase -A name-of-branch`).
You can also mark those local-only changes (both the merge-change and the local customizations) as private changes, to make sure you never actually push them.
[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...
[1]: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...