Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu (jj), a Git compatible VCS

tonyfinn.com

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#61

Post by [deleted] »

dsissitka wrote: post #58
stouset wrote: post #50

Earlier quoted context omitted.

And I remember everyone saying that git is confusing, that they get into states that they don’t understand and have to blow their local changes away, and that they have completely fucked their local copy more than once. I’ll give you some concrete advantages: 1. Every time you run a `jj` command a snapshot of your local changes is made. I don’t know about you but often while I’m working on something experimental I ha…

> 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.

[deleted]

Re: Jujutsu (jj), a Git compatible VCS

#62

Post by steveklabnik »

dsissitka wrote: post #58
stouset wrote: post #50

Earlier quoted context omitted.

And I remember everyone saying that git is confusing, that they get into states that they don’t understand and have to blow their local changes away, and that they have completely fucked their local copy more than once. I’ll give you some concrete advantages: 1. Every time you run a `jj` command a snapshot of your local changes is made. I don’t know about you but often while I’m working on something experimental I ha…

> 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.

Re: Jujutsu (jj), a Git compatible VCS

#63

Post by jjj123 »

JTyQZSnP3cQGa8B wrote: post #46
emacsen wrote: post #11

Earlier quoted context omitted.

There are three answers to this. 1. If it works for you, no need to stop I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control. If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down,…

> I remember plenty of people who used SVN saying why did they need to use git I remember everyone saying “SVN is a piece of shit, I hate it, why can’t I easily create branches.” Also mixed revisions which was the worst part of it. The jj people should really write a guide to show how it’s better than git because, so far, I’m still very confused and we’ve had that conversation on HN at least 10 times without anyone g…

The post you’re replying to gave 2 concrete examples.

Re: Jujutsu (jj), a Git compatible VCS

#64

Post by stouset »

edflsafoiewq wrote: post #31
MarceColl wrote: post #21

Earlier quoted context omitted.

Do you stash or create a commit with potentially partial work? What do you name that commit?

Personally I usually stash if it's partial work I'm going to return to soon. But you can create a commit if you want. Just name it 'WIP' or 'temp' or something. When you come back and finish it you can write the proper commit message.

And then you have to remember which branch the each entry of the stash was on, deal with unstashing conflicts, remember to drop the latest stash after fixing those, etc.

Tools like the stash are band aids that come with their own set of “fun” failure modes.

Re: Jujutsu (jj), a Git compatible VCS

#65

Post by stouset »

oxidant wrote: post #36
MarceColl wrote: post #21

Earlier quoted context omitted.

Do you stash or create a commit with potentially partial work? What do you name that commit?

`git add .`, `git commit -m "wip: some note about what I was doing" Then checkout the new branch and do my work. When I come back, `git reset --soft HEAD^`, and continue

Now let’s talk rebase/merge conflicts, stash conflicts, forgetting to un-wip, and on and on and on and then maybe acknowledge that all of these “but my git workflow is simple” comments are a convenient fiction that doesn’t actually exist in practice.

Re: Jujutsu (jj), a Git compatible VCS

#66

Post by [deleted] »

lawn wrote: post #3
cupofjoakim wrote: post #2

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…

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.

[deleted]

Re: Jujutsu (jj), a Git compatible VCS

#67

Post by stouset »

ocular-rockular wrote: post #4
lawn wrote: 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.

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 (and rebasing in general is) no longer painful. Jumping between work is a no-op. Fixing up earlier work is a no-op. There are no modal “interim” states like during conflicts where you have to abort or continue to get back to normal.

You don’t have to be a git god to run into the many sharp edges of git, and all of the “but my workflow is simple” comments break down upon even cursory inspection. Everyone’s workflow is simple until a rebase goes wrong, or they unstash in the wrong branch, or they need to unfuck an earlier commit, and that list goes on and on. And when you’re in these states you have no practical way to save or persist incomplete work.

Jujutsu is both more powerful and simpler, and I say that as someone who knows git inside and out and who’s used it pre-GitHub.

Re: Jujutsu (jj), a Git compatible VCS

#68

Post by stouset »

zug_zug wrote: post #13
ocular-rockular wrote: post #4

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…

Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss. Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten. IMO better to support the dominant tooling than invest in fracturing one of the few areas wher…

> Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten.

I was a git power user. I became comfortable enough with jj to replace git entirely in one day.

Re: Jujutsu (jj), a Git compatible VCS

#69

Post by dsissitka »

steveklabnik wrote: post #62
dsissitka wrote: post #58

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.

> The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.

That's one of the workarounds I had in mind. :)

This week I've had to work with CSVs, SQLite databases, and video in... six... different formats. Some goes in the repo, some doesn't.

It seems like my choices are:

- Disable it in the repo's .jj/repo/config.toml.

- Get people that don't like it to turn it off.

- Get people to do their exploratory coding in a gitignored directory.

It feels like any choice I make is going to be met with resistance.

Re: Jujutsu (jj), a Git compatible VCS

#70

Post by stouset »

neandrake wrote: post #8
lawn wrote: 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 theory yes. In practice I’ve had it enabled since it was first released and it helps… some?
Post reply on HN