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

91–100 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#91

Post by mamcx »

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…

> looks more complicated and verbose than regular gi

Is Git not verbose and complicated?

It is like the poster child of it among ALL THE OTHER options in his space!

---

I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years.

I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week.

And have some bash scripts around to automate how to back out of rebase hell.

Re: Jujutsu (jj), a Git compatible VCS

#92

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…

> IMO better to support the dominant tooling than invest in fracturing one of the few areas where engineers can agree on something for once

If Linus had this mentality we’d all still be using Subversion.

Re: Jujutsu (jj), a Git compatible VCS

#93

Post by stouset »

yuppiepuppie wrote: post #86
stouset wrote: post #77

Earlier quoted context omitted.

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

You don’t deal with rebase conflicts? You don’t ever unstash to the wrong branch? Or to the right branch, but it was changed and now it’s applied uncleanly? You don’t ever want to go fix a previous commit? You don’t ever need to do linear work that gets merged one piece at a time into the trunk?

All of these things (and others) can be worked around with varying levels of annoyance ranging from just living with it to new commands that help out to changing your workflow to completely avoiding some workflows. But in my experience nearly everyone deals with those annoyances on a semi-regular basis.

Re: Jujutsu (jj), a Git compatible VCS

#94

Post by stouset »

eikenberry wrote: post #83
steveklabnik wrote: post #82

Earlier quoted context omitted.

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 complet…

You live with those files showing up as untracked because it was easy and convenient to do so with git.

If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of place. You see files you don’t intend to include in `jj status` and you’d do whatever is appropriate to exclude them.

I’m with Steve here. I too was skeptical, and it’s turned out to be a complete non-issue.

> and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat

It’s even more trivial than you might imagine. If you have a commit that added files you don’t want to include you `jj edit` that commit, remove them however is appropriate (rm, mv, add to gitignore, whatever), and… there is no step 3. Later commits are instantaneously and automatically rebased so as to not include those files. Tools like filter-branch are completely unnecessary.

Re: Jujutsu (jj), a Git compatible VCS

#95

Post by stouset »

edflsafoiewq wrote: post #79
stouset wrote: post #64

Earlier quoted context omitted.

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.

If you don't like stash, then use WIP commits like I said. The easiest and by far most common thing to do of course is to just complete the commit you're working on before switching branches.

I have accidentally pushed wip commits more times than I care to remember.

Wouldn’t it be nice if there was a tool that didn’t need you to internalize all these workarounds?

Re: Jujutsu (jj), a Git compatible VCS

#96

Post by eikenberry »

stouset wrote: post #94
eikenberry wrote: post #83

Earlier quoted context omitted.

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 complet…

You live with those files showing up as untracked because it was easy and convenient to do so with git. If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of…

Cool. You've convinced me. A small change in workflow + easy cleanup sounds like it addresses most of my concerns. Though if I were to adopt jj I'd still probably just turn off the feature at first until I saw where I could have used it in practice. I'm going to wait and see for a bit myself. I'm pretty comfortable with git.

Re: Jujutsu (jj), a Git compatible VCS

#97

Post by edflsafoiewq »

stouset wrote: post #95
edflsafoiewq wrote: post #79

Earlier quoted context omitted.

If you don't like stash, then use WIP commits like I said. The easiest and by far most common thing to do of course is to just complete the commit you're working on before switching branches.

I have accidentally pushed wip commits more times than I care to remember. Wouldn’t it be nice if there was a tool that didn’t need you to internalize all these workarounds?

I don't believe I've ever pushed a WIP commit. Count that to the benefits of stashing I guess.

I don't consider any of this a problem, but why don't you tell me how your preferred tool does it.

Re: Jujutsu (jj), a Git compatible VCS

#98

Post by steveklabnik »

mamcx wrote: post #91
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…

> looks more complicated and verbose than regular gi Is Git not verbose and complicated? It is like the poster child of it among ALL THE OTHER options in his space! --- I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years. I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week. And ha…

You’re like the perfect audience for jj. Give it a try with some of your git repos. If you hate it, easy to go back to git afterwards. But I think you’ll like it.

Re: Jujutsu (jj), a Git compatible VCS

#99

Post by ocular-rockular »

mamcx wrote: post #91
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…

> looks more complicated and verbose than regular gi Is Git not verbose and complicated? It is like the poster child of it among ALL THE OTHER options in his space! --- I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years. I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week. And ha…

Not to me.

Re: Jujutsu (jj), a Git compatible VCS

#100

Post by stouset »

edflsafoiewq wrote: post #97
stouset wrote: post #95

Earlier quoted context omitted.

I have accidentally pushed wip commits more times than I care to remember. Wouldn’t it be nice if there was a tool that didn’t need you to internalize all these workarounds?

I don't believe I've ever pushed a WIP commit. Count that to the benefits of stashing I guess. I don't consider any of this a problem, but why don't you tell me how your preferred tool does it.

So when I say there a problems with stashing, you suggest wip commits. When I point out problems with wip commits, we go back to stashing?

jj needs neither because everything in your working copy is already part of a commit. You can’t accidentally push unfinished changes because jj will complain if it hasn’t been described (given a commit message). If you need to move changes between commits you don’t need to stash because you can easily move the contents of a commit around.

Post reply on HN