461–470 of 552 posts
Earlier quoted context omitted.
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.
There are some later additions like git switch, but git rebase and git commit ain't one.
Curious are there nice terminal tools for JJ similar to magit or GitUI?
Earlier quoted context omitted.
Most coding llms already know git, and can handle jj pretty well too.
I expect them to, I ment, that as part of modifying the code the issue commands that affect the VCS. This would be annoying, because you then can't rely on the VCS to tell you what the LLM did.
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…
There is a 3rd group (probably mostly gamedevs) who think it seems like a great idea and really want to try it, but are blocked waiting for git-lfs support. Every time jujutsu pops back up on HN I check to see if they've added it yet. Not yet! But they are slowly getting there: https://github.com/jj-vcs/jj/issues/80
Earlier quoted context omitted.
Most coding llms already know git, and can handle jj pretty well too.
I expect them to, I ment, that as part of modifying the code the issue commands that affect the VCS. This would be annoying, because you then can't rely on the VCS to tell you what the LLM did.
Earlier quoted context omitted.
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…
You can have merge conflicts, when you combine two commits (--amend in git terminology, not sure how it's called in jj)?
Earlier quoted context omitted.
Curious, I was under the impression that Google was all a monorepo, but your phrasing suggests that there are others. As my company is pushing for a monorepo, I'd love to know what causes someone at big G to not be in the monorepo. Thanks for any insights you can help me with!
Mainly open source stuff. Chromium, Android, etc.
I think all of those are using git and many Gerrit as well.
Earlier quoted context omitted.
That lets you see previously checked out revisions. Jujutsu keeps track of all previous repo state. In git, you can pull a new remote branch, delete that branch, and push the deletion. If you want to get that branch back, git reflog will only save you if you checked out that commit. If you didn't, you're SOL. Jujutsu will let you undo the delete operation, restore the repo to a state where the branch existed, or view…
What if you commit secrets to the repo by accident?
Earlier quoted context omitted.
I think you communicated well, probably I did not. > suspending the rebase and going to do something else This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. At first approach (I read a (very good) intro[1]; I did not try), it seems there’s a lot of new things to learn (for instance the…
> When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Rebase conflicts are (to a jj user) just another fix you might want to make to a revision. Or it might be better done by making a tweak to an earlier revisi…
Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing…
Relaxing this comment which is a bit aggressive: at least it’s how I work. YMMV.
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.
I used bisect once in my life but it was extremely helpful. Without it I'd spend weeks trying to find regression. With bisect I found and fixed it in under 1 hour. It's a command that is needed rarely but there's no replacement for it in some situations.
It might be slightly more tedious but couldn't you just do the same thing manually and it would add just a couple minutes to the search and you would still save weeks? I like the ergonomics but only use it once every couple years.