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

311–320 of 336 posts

Re: I see a future in jj

#311

Post by Dylan16807 »

coastalpuma wrote: post #306
steveklabnik wrote: post #271

Earlier quoted context omitted.

I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.

> The benefits touted are very abstract Not really? From someone's post here a year ago: > The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes…

Do I benefit from getting the same hash no matter what order I put the patches? In fact getting the same tree either way feels like information loss. Even if I only merge, won't I lose track of what the actual state was when each commit was made?

Most of my wrestling is with merge conflicts and a consistent tree doesn't help with that.

Re: I see a future in jj

#312

Post by Iwan-Zotow »

1718627440 wrote: post #219
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…

git rebase --update-refs

Won't work, only tree

Re: I see a future in jj

#314

Post by pm215 »

steveklabnik wrote: post #294
pm215 wrote: post #287

Earlier quoted context omitted.

On that first point, there's a use case I sometimes have where stgit feels very clunky: * I have a branch foo with a stack of patches which are the thing I'm working on, based on a master branch * I have a separate stack of patches on a branch bar (let's say this is a feature that interacts with foo but it's not ready to upstream yet or maybe at all) * I want to test and work on the combination of foo and bar and mak…

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.

Re: I see a future in jj

#315

Post by KingMob »

1718627440 wrote: post #217
KingMob wrote: post #194

Earlier quoted context omitted.

There's a variety of things that all add up to a very pleasant experience. For starters, git has a poorly-designed UI, whereas jj borrows from Mercurial, which was widely-considered to be better designed from a DX perspective. I can usually guess what commands and flags to use on jj without reading the manual; not so for git. E.g., `jj undo` undoes anything you might have done; For anything esoteric in git, I consult…

> There's no need for staging or stashes in jj. What the JJ developer seam to misunderstand is, that the index and stashes are a feature to improve the users workflow. You can bypass the index with commit -a, giving you JJ behaviour and you can commit just fine instead of using the stash. The stash is like some backlog of temporary commits and also supports saving the index separately. When you don't care about this,…

With the way jj works, all the functions of indexes and stashes are handled with commits.

There's no loss of speed, functionality or power, and as a bonus, instead of maintaining 3 separate concepts and commands, they're now handled by 1.

It's honestly much simpler. A git stash is effectively a commit already, but stored weirdly, doesn't show up in the logs by default, and with its own ad hoc commands.

Re: I see a future in jj

#316

Post by KingMob »

1718627440 wrote: post #299
SAI_Peregrinus wrote: post #273

Earlier quoted context omitted.

The same way Git ensures that no two repos generate the same commit ID: by using a cryptographic hash function.

What does JJ hash here, when I can modify the whole commit, but the change id stays constant?

The parent comment is wrong.

Generally, when a new change ID is needed, jj generates a random number. The individual commits under each change still use hashed SHAs.

> when I can modify the whole commit

You can't actually modify any commits. A mutable change can be thought of as a subset of immutable git commits with a pointer to the most recent commit.

When you alter a file and jj snapshots, it adds immutable commits to the DAG end, and updates the pointer.

---

There's some exceptions, like when importing from git, it will generate new change IDs based on a transform of the git SHAs.

---

Side note: as much as I like jj, I admit the change/commit terminology is confusing as hell.

Re: I see a future in jj

#317

Post by pm215 »

1718627440 wrote: post #300
pm215 wrote: post #257

Earlier quoted context omitted.

I find myself from time to time with stuff in the index (merge conflicts in particular I think can result in this). I never put anything there explicitly. I would love to be able to configure git such that the index didn't exist, but I can't.

The transparent thing would be to put everything into the index, and configure all the commands to autoupdate the index. This is what happens with the merge conflict, because there is no benefit having resolved merge conflicts not already in the index. So the merge conflicts already do what you want, the other commands need to be modified.

That isn't what I want, though. I don't see any point in the index as a construct -- I am happy with changes being either (a) not in any commit, just in the working directory or (b) in the most recent commit. Somewhere lurking in the middle is just confusing.

Re: I see a future in jj

#318

Post by steveklabnik »

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.

Most of the time in jj you don’t even rebase manually, because it’s automatic. And the vast majority of the time, I’m using one or two flags to rebase if I am calling it. You might even need only two in this case (before only might be fine?) I just use both before and after because it’s so easy to remember the names.

Anyway you should use the tools you like, it’s all good.

Re: I see a future in jj

#319

Post by 1718627440 »

steveklabnik wrote: post #307
1718627440 wrote: post #301

Earlier quoted context omitted.

JJ has a backlog of temporary commits? That's a stash under another name.

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.

Re: I see a future in jj

#320

Post by bagxrvxpepzn »

SAI_Peregrinus wrote: post #259
bagxrvxpepzn wrote: post #46

Earlier quoted context omitted.

> it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular. The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is…

The substantial technical difference is that the UI (the "porcelain") of JJ is not backwards-compatible with that of Git, even though it can use git's "plumbing". `jj commit` works differently than `git commit`, and Git can't match that without a similar compatibility break. JJ uses Git's "content-addressed DAG of snapshots" data model in a particularly elegant way, and deletes many redundant commands to achieve that…

There must be a miscommunication somewhere because your entire comment seems to reinforce rather than refute my point.
Post reply on HN