471–480 of 552 posts
Earlier quoted context omitted.
Care to elaborate on the hassle and lack of upsides? Have you considered that you simply didn't give it a fair shake or were holding it wrong?
I don’t think this is a good approach toward getting people to switch. It’s unnecessarily combative.
The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually cop…
Earlier quoted context omitted.
> create multiple directories (workspaces) backed by a single repository at different commits This is `git worktree`. They don't work with submodules but submodules are a disaster that should be avoided anyway so probably no big loss there.
Ah, I was not familiar with that feature in git. In that case, I'll swap out jj workspaces for sparse checkouts :-)
Earlier quoted context omitted.
Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.
The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage. I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.
It's really important to catch bugs early, because it's a lot more expensive to fix them later -- even if only as late as in CI before merging.
If only it was supported by Gui tools... I don't bother use Git from my terminal, but use GiFork instead. As I understand there is nothing that may be interesting for me in my scenario...
Earlier quoted context omitted.
I have a bad habit, even still, of just working in one monster commit. It took me a few months to realize that I could use jj split to move specific files to a different commit. And then I'd sometimes squash them into related commits, rebase to move them around etc... But I just discovered interactive split, which lets you move specific lines and sections from different files in a commit to a different commit. So I'v…
One really nice trick you can do is: - Create multiple topic branches, one for each thing you're working on. - Now you probably want to work on item A while having B and C all available, so make a single merge commit (jj new a b c) to build on top of. - Create further commits on top of that, while you're working. - When you're cleaning up (ideally often), use squash --to or rebase --after to move those commits back t…
I haven't 'got' it yet. I am sure I will after some regular use.
But being a long time Magit user, its hard to move to anything else.
My NixOS repo checkout(s) are always cursed with unstaged changes, will jj help me cure this? Sometimes I feel like "this shit is too bad to commit but it does the plumbing for the thing I'm working on right now" and it ends up untracked for weeks... This is just my personal ADHD pool of code but it gets really gnarly before I take care to dissect my unstaged changes into the repo.