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

jj – the CLI for Jujutsu

steveklabnik.github.io

Post reply on HN
Print view View original

271–280 of 517 posts

Re: jj – the CLI for Jujutsu

#271

Post by steveklabnik »

brendoncarroll wrote: post #245
waynecochran wrote: post #234

Anything new or special in jj that allows me to work with large binary files simply? To me, this is still unsolved in terms of providing an elegant solution (e.g. things like Git Large File Storage (Git LFS) are awkward).

I've heard that jj has support for non-git backends? Can anyone comment on how difficult it would be to add support for another backend, any docs or examples? I have a project[0] that does the large file thing well, but is missing most of the version control porcelain. I've been looking for the path of least resistance to integrate it into something with a larger user base. [0] https://github.com/gotvc/got

To add a new backend, there's a trait that you implement for your backend: https://github.com/jj-vcs/jj/blob/713a0d0898448392d38fdcbaba...

I suspect if you came by the jj discord, folks could help you with more detail than that.

Re: jj – the CLI for Jujutsu

#272

Post by ncphillips »

__turbobrew__ wrote: post #258
octocop wrote: post #157

Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.

The feeling I get with jj is it is almost like people are trying to convince others why jj is superior instead of just sharing that jj exists and let others decide themselves. It seems like every few months there is a jj post on HN which devolves into the narratives of “git works for me” and “but jj is better at X”.

Where X = something I’ve never wanted to do

Re: jj – the CLI for Jujutsu

#273

Post by ersatz-matty »

coldtea wrote: post #225
EliasWatson wrote: post #211

Earlier quoted context omitted.

A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later. - Manipulating commits is super easy (especially with jjui). I reor…

All of these features sound like the recipe for a confusing nightmare! "You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later." "Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I wa…

In practice, it isn't. What you're identifying as potentially nightmarish - and no doubt quite tedious in git - are things that JJ enables you to do with a small subset of commands that work exactly how you expect them to work _in every workflow context_ in which they are needed.

Thinking specifically about conflicts: being able to defer conflicts until you're ready to deal with them is actually great. I might not be done with what I am actually working on and might want to finish that first. being forced into a possibly complicated conflict resolution when I'm in the middle of something is what I'd actually consider nightmarish.

When you want to solve the conflict: `jj new `, solve the conflict, then `jj squash`, your conflict resolution is automatically propagated to the chain of child commits from the conflict.

Re: jj – the CLI for Jujutsu

#274

Post by steveklabnik »

bikelang wrote: post #259

Reading threads like this and the GitHub stacked PRs just makes me feel like an alien. Am I the only one that thinks that commits are a pointless unit of change? To me - the PR is the product of output I care about. The discussion in the review is infinitely more important than a description of a single change in a whole series of changes. At no point are we going to ship a partial piece of my work - we’re going to s…

You're not an alien: this is the workflow that GitHub encourages.

It's just that not every tool is GitHub. Other systems, like Gerrit, don't use the PR as the unit of change: they use the commit itself. And you do regularly ship individual commits. Instead of squashing at the end, you squash during development.

Re: jj – the CLI for Jujutsu

#276

Post by ncphillips »

Jenk wrote: post #41
enbugger wrote: post #40

1) Are there any benefits in replacing a personal private project git repo with jj? I usually just commit straight to master in order to just not to lose the changes and be able to roll back. 2) Are there any pros in doing so in a project with many large binary files (3d models, images)?

You don't replace. jj is backed by git anyway.

Okay but why would they use jj when they do trunk-based dev

Re: jj – the CLI for Jujutsu

#277

Post by kps »

tom_alexander wrote: post #141
saghm wrote: post #84

Earlier quoted context omitted.

How are you "checking out" the old commit? It sounds like you're using `jj edit`, which I'd argue does what it says on the tin. Switch to using `jj new ` and your problem goes away.

That avoids the problem for the specific workflow of checking out an old revision (and it was what I was describing with checking out a new branch off the old commit and adding a blank commit to that branch), but another way this design bites me: At work I am constantly jumping around numerous repos because I might be working on repo but then someone on my team will ask for help with repo . So I'll turn on screen sha…

I think you have somehow picked up an overcomplicated workflow, and this is case is actually something that `jj` is much better at.

If I'm in the middle of working on and someone asks about : `jj new `. When I'm done (and do whatever I want with those new changes in , including deferring deciding what to do), I just `jj edit ` and I'm back exactly where I left off. It's a bit like `git stash` without having to remember to stash in advance, and using regular commit navigation rather than being bolted on the side.

Re: jj – the CLI for Jujutsu

#278

Post by steveklabnik »

klauserc wrote: post #247
steveklabnik wrote: post #170

Hey folks! So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it. Happy to answer any questions!

jj automatically hides "uninteresting" changes. Most of the time, this is good. Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?

I use `jj log -r ..` for that, which is just an open ended range. It's not the "15 more" but it's what's worked for me. I suspect you could do it with some sort of revset stuff, but I like to keep it simple.

Re: jj – the CLI for Jujutsu

#279

Post by chriswarbo »

tiborsaas wrote: post #54

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…

> It wants me to start with the new and describe command

jj doesn't "want" anything.

I always end a piece of work with `new`: it puts an empty, description-less commit as the checked-out HEAD, and is my way of saying "I'm finished with those changes (for now); any subsequent changes to this directory should go in this (currently empty) commit"

The last thing I do to a commit, once all of its contents have settled into something reasonable, is describe it.

In fact, I mostly use `commit` (pressing `C` in majutsu), which combines those two things: it gives the current commit a description, and creates a new empty commit on top.

Re: jj – the CLI for Jujutsu

#280

Post by tombert »

newsoftheday wrote: post #275

OK I read it, I'm not interested, git does exactly what I want.

That's sort of where I've been stuck with with jj.

Maybe someone can convince me otherwise, but to me it hasn't felt sufficiently better than git to justify bothering re-learning this stuff, even if it's relatively easy.

Post reply on HN