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

I see a future in jj

steveklabnik.com

Post reply on HN
Print view View original

321–330 of 336 posts

Re: I see a future in jj

#321

Post by steveklabnik »

antonchekhov wrote: post #161
steveklabnik wrote: post #82

Earlier quoted context omitted.

Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.

I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool ( https://cli.github.com ) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly + to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had si…

I'm a big CLI for VCS person, so yeah, I use those tools too :)

Re: I see a future in jj

#322

Post by steveklabnik »

1718627440 wrote: post #319
steveklabnik wrote: post #307

Earlier quoted context omitted.

Not exactly, but sorta. You don't need to write a description for a commit, and it doesn't need to be on a branch, and things are auto-committed. So if I'm working on something, and then I "jj new" to start something else somewhere else, I can trivially come back to what I was doing. You're right that's a stash under another name: a commit. But the key is, because it's not a special separate thing from a commit, I ca…

I was talking about: > backlog of temporary commits So a list somewhere else, which commits are considered temporary. It's a todo list for commits. Does JJ have that? > We've unified two things into one thing. A stash in Git is also just two commits. So no you just removed a feature on top of that. That feature might not be to your taste, or even outright confusing, but you did remove it.

I am saying a feature was removed, yes. But what I'm saying is, the things you use that feature for can still be accomplished. It's just not accomplished via a dedicated feature, but as an effect of how other features work.

Re: I see a future in jj

#323

Post by constantius »

steveklabnik wrote: post #67
constantius wrote: post #65

Earlier quoted context omitted.

I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything…

That's correct, it will do the cascade rebase of everything automatically.

Thanks Steve, and for the tutorial too!

Re: I see a future in jj

#324

Post by nonethewiser »

steveklabnik wrote: post #291
nonethewiser wrote: post #281

Earlier quoted context omitted.

Yes. I could see confusion about the term "parent" but get? IDK what the confusion is there.

It was just like, in what context? To print a log? To rebase something? "get" is not a command exactly. That's it. Some of it is also what a "branch" means to different people can mean different things: https://jvns.ca/blog/2023/11/23/branches-intuition-reality/ But yeah, as others have said, not really possible in a general way, sadly.

get as in find, retrieve, identify, etc. Im talking about a use-case not a git feature.

Re: I see a future in jj

#325

Post by nonethewiser »

klardotsh wrote: post #296
nonethewiser wrote: post #282

Earlier quoted context omitted.

Should I learn this thing or wait 4 months until the next LLM refresh might have ingested it?

This feels like the same question as in consumer goods: "do I buy this thing now, or do I wait for the potential refresh in 6mo to see if it's better?" Just get the thing you need now, there's no promise the grass is getting any greener, nor that you're any better off waiting. Maybe the LLM won't learn for 6 months. Or 12 months. Or maybe the AI company will run out of money, or jack up their prices to where you're n…

I was asking in jest, but yeah

Re: I see a future in jj

#326

Post by ldrndll »

pm215 wrote: post #314
steveklabnik wrote: post #294

Earlier quoted context omitted.

jj does do better here: its called the "mega merge" https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... Combined with jj absorb, some people just work this way all the time, even. > I like having a straightforward stack of patches that I can push, pop and reorder and list. You can work this way too, what you'd want is `jj rebase` with -A, -B, and -r: r for the revision, and A and B for the before and afte…

What I mean is that I do not want a single "swiss army knife" rebase command that does everything with lots of options to remember. It's fine to have that in the toolbox for the once in six months weird requirement. But for the simple cases I do every day I want simple commands that each do one thing and have memorable names.

If I'm understanding you correctly, you can have both. If there are specific rebase types that you perform regularly, you can create aliases for them and give them whatever name is meaningful to you.

For example, I frequently use `jj up` to rebase the current branch on main. Likewise, `jj pop` rebases just the current commit (popping it from its current place). I even have a `jj ppop` - better name suggestions are welcome - which does this but for the parent commit.

I suspect that the once-off effort to write your own commands would take no longer than it would take to read the documentation if the commands already existed, but with the hopeful extra benefit of giving you a better understanding of how to use rebase for those once in six months weird requirements when they may arise.

But to be clear, I'm not suggesting you must or even should put in this effort if you have something that works for you. My reply is mostly so that anyone who comes across this discussion and sees Steve's mention of -A, -B, etc isn't scared off by them. Whilst they're always there for you, you can use the power it gives you but in the form of single function commands that don't require you to think.

---

For anyone wondering, the aliases I mentioned. These can be dropped in your jj config with `jj config edit --user`.

  [aliases]
  up = ["rebase", "--skip-emptied", "-d", "trunk()"]`
  pop = ["rebase", "-r", "@", "-d", "trunk()"]
  ppop = ["rebase", "-r", "@-", "-d", "trunk()"]

Re: I see a future in jj

#327

Post by steveklabnik »

nonethewiser wrote: post #324
steveklabnik wrote: post #291

Earlier quoted context omitted.

It was just like, in what context? To print a log? To rebase something? "get" is not a command exactly. That's it. Some of it is also what a "branch" means to different people can mean different things: https://jvns.ca/blog/2023/11/23/branches-intuition-reality/ But yeah, as others have said, not really possible in a general way, sadly.

get as in find, retrieve, identify, etc. Im talking about a use-case not a git feature.

Yeah now I got it! Just me being a bit confused, it's a me thing, not a you think :)

Re: I see a future in jj

#328

Post by 1718627440 »

steveklabnik wrote: post #322
1718627440 wrote: post #319

Earlier quoted context omitted.

I was talking about: > backlog of temporary commits So a list somewhere else, which commits are considered temporary. It's a todo list for commits. Does JJ have that? > We've unified two things into one thing. A stash in Git is also just two commits. So no you just removed a feature on top of that. That feature might not be to your taste, or even outright confusing, but you did remove it.

I am saying a feature was removed, yes. But what I'm saying is, the things you use that feature for can still be accomplished. It's just not accomplished via a dedicated feature, but as an effect of how other features work.

Yeah and I am saying that you could do that as well with Git. Git just also does have that feature and a lot of users like to use that, but you don't need to.

Re: I see a future in jj

#329

Post by tom_ »

jasonpeacock wrote: post #278
tom_ wrote: post #140

Earlier quoted context omitted.

1. Perforce checkout requests always do the round trip to the server. 2. Artists can actually understand Perforce.

> Perforce checkout requests always do the round trip to the server That's literally the antithesis of Git. If that's a requirement, then yeah - Git's the wrong thing. It's like complaining that bicycles don't have motors like motorcycles. If it had a motor, it wouldn't be a bicycle.

The question as I recall was what Perforce does that Git LFS doesn't, so I'm sorry to disappoint but my hands were tied.

Anyway, I dunno, man. If you want binary files to work, some form of per-file mutex is indeed a requirement. And for this to work well, without being a lot of hassle (and regarding that, see point 2, which I note has been accepted without comment - not that I expected anything else, the argument that Git is the artist-friendly choice would be a difficult one to make), any modification of the mutex's state has to involve a round trip to ensure the info is up to date. You can't rely on something local, that only gets updated sometimes, because then the info can be out of date! Worst case, N people find out too late that they've all been making changes simultaneously, and now N-1 of them will almost certainly lose work.

(You might be inclined to moan at people for not going through the full process, but: we have computers now! They can do the full process for us!)

Re: I see a future in jj

#330

Post by dijit »

jasonpeacock wrote: post #279
dijit wrote: post #176

Earlier quoted context omitted.

This is what you want to believe but its not true. I’m really sorry, git lfs is an ugly hack, and its always painful when you discover that some gamedev team has been forced into it by “better knowing” software developers. It reminds me a lot of “features” of software that is clearly a box ticking exercise, like technically MS Teams has a whiteboard feature. Yet it lacks any depth: its not persistent so its gone afte…

Not a belief, but my experience. Maybe I've had a blessed experience with LFS? It's always "just worked" for me.

But I’d make a guess that the majority of the files you’re working on are text based.

If the primary filetype you use is binary, you’ll start to feel the jank.

Post reply on HN