31–40 of 128 posts
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?
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’ve been slowly working on a patch-bin service that only has access to patchsets and doesn’t have access to the git repo itself. As a result the best we can offer is range-diff. It’s a pretty interesting workflow and makes the collaboration software easier to maintain: https://pr.pico.sh
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?
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 the main problem it solves is stacking https://www.stacking.dev/
For what it’s worth from what I’ve read about JJ: it’s a better VCS frontend overall.
Earlier quoted context omitted.
I think the main problem it solves is stacking https://www.stacking.dev/
That’s a problem created by GitHub or people unable to think outside of the GitHub model. It would make more sense to solve that problem through a review tool. For what it’s worth from what I’ve read about JJ: it’s a better VCS frontend overall.
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…
Although it is currently undocumented, since v0.21.0 you can make `--edit` the default by adding the following to your configuration: [ui.movement] edit = true Ref: https://github.com/jj-vcs/jj/pull/4283
If you clone the repo there’s a bunch of documentation and example files, but if you install jj, those do not exist.