Live data from Hacker News

Jujutsu (jj), a Git compatible VCS

tonyfinn.com

81–90 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#81

Earlier quoted context omitted.

> Every time you run a `jj` command a snapshot of your local changes is made. I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.

I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory. The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.

Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad decisions have gone into the project.

Re: Jujutsu (jj), a Git compatible VCS

#82

Earlier quoted context omitted.

I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory. The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.

Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad…

It’s consistent and convenient.

I was skeptical until I tried it.

Re: Jujutsu (jj), a Git compatible VCS

#83

Earlier quoted context omitted.

Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad…

It’s consistent and convenient. I was skeptical until I tried it.

I'm a bit more than skeptical. Right now, for a project at work, looking at files in the repo (for testing, etc) I have 294 files untracked and 10 ignored. Using jj all but the ignored files would be committed to the repo and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat.

I guess I should ask... is that final step made super easy? That is does jj make it easy to completely remove all traces from the repo of those auto-added files (like filter-branch)?

Re: Jujutsu (jj), a Git compatible VCS

#84

Earlier quoted context omitted.

Git’s rerere functionality should address this, right? https://git-scm.com/book/en/v2/Git-Tools-Rerere

I'm not a heavy jj user. But as I understand it, git-rerere is bolted on top and not well integrated. It just stores resolutions locally on each machine in .git/rr-cache. You need extra steps to share resolutions between contributors. https://stackoverflow.com/questions/12566023/sharing-rerere-... In jj, resolutions are first-class objects—treated the same as any normal commit, pushed/pulled like normal, etc.

rerere is indeed bolted on.

Linus doesn’t want people who he pulls from to back-merge, i.e. to merge at “random points” from him into their trees to keep up to date. But what about merge conflicts? Then he has to deal with them. So then he might begrudgingly ask them to back-merge right before making a pull: a real zig-zag pattern.

First-class conflicts would solve all that I think.

Re: Jujutsu (jj), a Git compatible VCS

#85
post #67

Earlier quoted context omitted.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

Because every person in here who’s actually used jj is telling you straight up that it’s less complicated. Using jj is less complicated in—as far as I can tell with six months of conversion—actually 100% of the time. I spent one day adapting and maybe two week of having to look something up every other day. And now all of git’s infamous pain points are gone. There is no index. There is no stash. Rebase conflicts are…

Okay, happy it works for you. Still don't see a point.

Re: Jujutsu (jj), a Git compatible VCS

#86
post #77

Earlier quoted context omitted.

Anecdata: I have no issues with my simple git workflow that I’ve used at the previous 3 companies I’ve worked for. As long as communication is solid across teams/people, merge conflicts and rebasing isn’t that big of a pain to introduce an un proven tool to an org. My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.

> to introduce an un proven tool to an org Your org doesn’t have to adopt the tool. Nobody on my team needs to know or care that I use jj instead of git. The only people who do know or care have themselves switched when I showed it off to them. I’ve worked too many places where I’ve helped fix too many coworkers’ broken git repos to believe in a simple git workflow. Basically everyone uses the same fetch/branch/commi…

But I don’t see the complaints that were claimed. I help people as well. They learn, and we move on. If they don’t learn then we have another problem to solve.

I will admit there is occasional call where I have to get someone out of a twisted pretzel, but that is few and far between.

Re: Jujutsu (jj), a Git compatible VCS

#87

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

I find the most benefit from `jj` when I'm preparing some commits for review and I want to make them tell a coherent story. I often want to then rearrange commits, split or merge them, move things from one to another.

For people who work on repos by themselves or with a small number of others, the advantages of `jj` would be smaller in most cases, I would think.

Re: Jujutsu (jj), a Git compatible VCS

#89

Earlier quoted context omitted.

I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the…

> why would the contributors to jj not just try to make git better by addressing these weaknesses? Because jj isn't being built to improve git, but to allow using git at Google to work on Piper-backed code instead of hg/fig, and adding support for the abstractions that are needed to support git and piper was probably seen as free complexity on git's side.

This is slightly incorrect. I started it because I believed in the idea of modeling the working copy as a commit, but it's true that I made the storage pluggable from the beginning because I wanted to be able to convince my team at Google that we should use it internally too.

Re: Jujutsu (jj), a Git compatible VCS

#90
post #3

Earlier quoted context omitted.

One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.

Git’s rerere functionality should address this, right? https://git-scm.com/book/en/v2/Git-Tools-Rerere

In some cases, yes, but I think the way jj handles conflicts is easier to follow. You can see the conflict resolution in `jj diff` and you can rebase it like a regular commit. rerere's state is harder to understand, I think. See https://github.com/martinvonz/jj/issues/175#issuecomment-107... for some more discussion.
Post reply on HN