441–450 of 552 posts
Earlier quoted context omitted.
Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.
Bisect is a wonderful feature. Git is full of tedium and frustration, bisect is not part of that.
Earlier quoted context omitted.
In jj you tend to use `jj split` to break changes apart. The selected bits become the first revision, the remaining bits become the second revision. I tend to do a bunch of work then split into small, bite-sized revisions. Often I split something out to a parallel revision (e.g., a separate branch) if it’s an independent thread of work like a bugfix elsewhere or a documentation fix. This is an obvious one-liner in jj…
I feel like I already lost more time reading this than jj would make me win if I switched :-).
For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…
> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim , the b…
Earlier quoted context omitted.
Bisect is a wonderful feature. Git is full of tedium and frustration, bisect is not part of that.
Yes not using bisect, seams like you do all the work to record information, but then never use that information to save work?
Earlier quoted context omitted.
> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks You can use git commit --fixup to record what you want to change in an earlier commit. > start over from scratch rerere > Branches based off your original changes don't get rewritten As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.
Yes, there are a million weird band-aids that git has grown over time. Some of them work better than others. Or we could just not have the problems to begin with.
Earlier quoted context omitted.
Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.
There were (are?) people who say the same thing about svn
Earlier quoted context omitted.
You'll love jj, as you've already been able to see the the light with new tooling like uv. Jj is to git what uv is to other python tooling. Check out jjui as well, which makes jj even better. https://github.com/idursun/jjui https://mise.jdx.dev is equally as revelatory as jj and uv
mise is awesome. Put it off far too long after a bad first experience. Now I'll never go back to asdf
IMO this is all being driven by Rust. jj, mise, ripgrep, fd, bat, eza, delta… all of the best of breed tools these days seem to be coming out of that ecosystem.
Earlier quoted context omitted.
Ah, so when people here talk about changing commits they are actually talking about changing changes (nicely named, indeed)? What happens when you merge or split changes with the change history? It sounds a bit like applying a VCS on top of a VCS.
Yeah so people will be a bit loosey-goosey with the terminology. But all of these changes are immutable, that is, when you change a change, you’re generating a new commit. “A VCS on top of a VCS” isn’t a terrible way of thinking about it: imagine if every commit in your repo had its own history. Merging is making a change that has more than one parent. You can then resolve any conflicts within that change. Splitting…
Earlier quoted context omitted.
Let’s say you’ve checked out a new branch and done a bunch of work over the course of the last two hours. 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…
This is the kind of example that I find insightful. I know I can do it with git and it's not hard. It's not fun, but it's not hard. So I will disagree with anyone who says that it's impossible with git. 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.
Earlier quoted context omitted.
I also work this way. A commit is really about, well, committing that these are exactly the right lines of code I intended to write. I also read them in another program, so it gets easier to not think that I already know the code and skip over. I basically start from the clean state (no changes) again and approve the changes line-by-line according to whether they fit the domain model of the program, whether they are…
>A commit is really about, well, committing that these are exactly the right lines of code I intended to write. That would be a ‘change’ in jj. A commit in jj is more like SQL than git; it's the end of a transaction, not a value judgement.