Git has worktrees for that. If a parallel change is done in a separate worktree, it can be built and tested independently, which, I guess, is important for kernel developers, who are the initial target audience for git.
I've never really struggled too hard to get git commits into different branches for review, but if you've put unrelated changes into the same working dir, you'll want `git add -p` to sort them out into multiple commits.
Note there are corresponding `-p` flags for things like git-restore and git-reset as well.
You’ve added a new feature. In doing that, you’ve also fixed four unrelated bugs, clarified the documentation for a method you needed to use, and rewritten another function to be more performant.
You could push this all as six commits on one branch. PR reviewers will now have to figure out what parts are related to what, or read each commit one-by-one. If someone wants changes to one of these commits, your entire branch is held up.
Or you could split these six different commits out to each be directly on `main` and make a PR for each of them. They can be tested in CI, reviewed, and merged in isolation.
The latter is far better. You can do it in git, but it’s not exactly fun. It is trivial in jj.
No, I'd probably put them all as individual branches to be reviewed, assuming they're truly independent changes. As long as they don't actually conflict it's not very hard to do this in git.
But this is kind of what I mean when I say that git fits my needs, because I wouldn't come across 4 unrelated tasks like this in the course of implementing a single commit's worth of features, unless I was having the world's biggest attack of ADD.
And if these things did need to get done to properly implement the feature to our team's quality standards, it would be appropriate to be included in that feature's PR as well.
I'm sure it's a nice tool, especially for those who work in domains where it takes a long time to land your commits into the main branch of development, but a lot of this sounds like solutions to problems that we don't all have.
But it is great to know that it is trivial in jj. That's a reason to try :-).
Everything feeling like it’s a slightly uphill battle isn’t something you always notice until it’s suddenly gone.
It is in fact a great tool, jj makes doing this even easier.
At least uv solved real problems I was having with Python package management, but for my own personal usage git is 99% aligned with what I need.
jj just makes all of the stuff I liked to do with git easier and faster, and lets me do some things you can’t do with git.
But you should use the tools you want to use.
> Now I am not one of those "the git CLI is too complex and git is too hard to learn" people, but I do acknowledge that puts me in the minority. But let's reframe that: if we can make something more powerful and easier? Sign me up!
That's nice.
I know of him better from his Rust work, but he explained himself well enough in his own comment that he probably doesn't need your assistance to reiterate a point he made very effectively on his own.
Also, he's not the only one who's used git since the early days.
They're useful, but they're not really what your parent is talking about, your parent is talking about a workflow where you realize you've want to break up your work after the fact, rather than setting out to do it that way from the start.