Hacker News Reader

Comment by ants_everywhere | Hacker News Reader

I'm confused what this is?

Is it just a git frontend for people who are confused by git?

It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits.

Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem.

The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking.

View on HN

> Working copy as commit means you have no quality control

The working copy doesn't get automatically pushed to GitHub or anything crazy like this seems to be implying. You review/curate your commit when you give it a description.

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits.

Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there.

> Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem.

Sorry, but saying this implies you haven't tried it. :-)

Jujutsu commits aren't equivalent to Git commits. They're implemented with a mixture of Git commits and the Git working tree, yes (if you use the Git backend!), but when you see 'commit', you should read 'named diff'.

Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream.

You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. jj makes that much MUCH easier than rebases and history edits could ever be with git. Most of my nontrivial jj work involves at least three or four commits at some point, everything from experiments to documentation branches, which with git I would have needed to awkwardly fit into stash or inconvenient throwaway branches.

Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search.

> You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream.

My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. The FAQ suggests this isn't possible and that you should work around it by using a separate branch and then merge into your target branch, which is a pretty ugly workflow.

Their GitHub branches are a mess of auto-generated strings, which suggests to me that this problem isn't just an abstract concern but is a form of technical debt that the jj devs are currently piling up.

> What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready.

Yes, it's "committed", but that doesn't mean all that much. I have the fsmonitor feature enabled that continually watches my repos as I edit files in them. This means that over the course of a coding session, the revision I'm working on has probably pointed at dozens or more ephemeral underlying git commits. Those are only kept around for the purpose of the evolution log, which lets me look back at my edit history throughout the day even without having interacted with the repo.

When you're ready to "finalize" your work, you have two common workflow options: you can `split` the out parts you want to keep as one consistent commit, which dumps the rest in a subsequent revision. Spiritually this is equivalent to `git add -p`. Alternatively, you can create an empty "staging" revision before your "working copy" revision and `jj squash -i` pieces you're happy with into there. In practice, many people use both. I generally do the former for new work, and the latter to make changes to earlier work.

Thinking that `git add -p` was absolutely a deal-breaker is the main reason I passed over jj for so long. I care deeply about maintaining a clean commit history with small, isolated, and individually-tested changes. I thought jj would make that harder due to not having a staging area. I was wrong. It is actually far easier to be principled about your commit history with the tools that jj gives you.

I don't mind the workflow of selecting what you want at a later time, but my concern is with having changes visible to the local repo database automatically.

If you like it that way, that's cool with me.

But to me personally I'd rather have the filesystem doing snapshots and not comingle fs snapshots with VCS. I can nuke an fs snapshot in a single line of bash if I accidentally leak something, and fs snapshots don't contribute to the slowness of a big repo. But those are problems in regular git and would be even bigger problems in a version of git that treated VCS as if it were an fs snapshot system.

But like I said if that works for other people that's great. It would probably work for me if I were a consultant working on a lot of small repos. I don't think it scales to a bigger repo unless the jujutsu repos are completely destroyed every few days, which is essentially what happens to CITC client working copies at Google.

> I can nuke an fs snapshot in a single line of bash if I accidentally leak something, and fs snapshots don't contribute to the slowness of a big repo.

Leaking isn’t really a concern; none of these ephemeral commits ever leave your local machine. I have used jj on a very large monorepo with > 10yr of commits, and I never noticed a performance issue.

jj was literally created by Googlers at Google for the purpose of being used at Google. I have no idea how that’s going, but it makes me suspect that it works better at that use-case than you’re giving it credit for.

> What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready.

You're thinking in very git-specific terms. JJ is just different in many ways so such comparison doesn't work well. I didn't get it from explanations before, but trying it in practice, it's a non-issue. It may be easier to just give it a go.

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready

Since you brought this up, I've noticed some people seem to work this way but I've never found anyone to ask why they do this.

I get the idea behind clean, readable git logs with nice consistent messages, but isn't that what rebase/amend is for?

To me, the status of my local git log is mostly irrelevant, the thing that really matters is the commit(s) I submit for merging.

Also, probably for related reasons, I've never truly understood why git has this whole separate staging concept...

I also work this way. A commit is really about, well, committing that these are exactly the right lines of code I intended to write. I also read them in another program, so it gets easier to not think that I already know the code and skip over. I basically start from the clean state (no changes) again and approve the changes line-by-line according to whether they fit the domain model of the program, whether they are in the right places, are the right amount of complexity/abstraction, if they are readable/understandable. I typically also add/remove comments at that point, because I've now tried to read the code with a "second pair of eyes".

I also use this to compare the changes to the commit messages. Ideally the changes follow from the message, not the other way around.

While a VCS is also useful for adding a time-axis to code, for me the main selling point is, that it's adding causality to the code. You can ask 'Why is this code how it is?'. (Of course causality is a side-effect of time.) When you don't curate the commits you completely loose this feature. (You can still ask, but the answers will be confusing and need way more work, which for me amounts to manually comparing commits to grasp the big picture and intention.)

> rebase/amend

When you messed up, you can of course change commits, but this has a danger of creating a version that was never there or mixing history, for example combining a single physical change, that are multiple logical changes. In order to test that the code at least works I use ```git rebase --exec="make -C build distcheck"```, not sure if that is common.

I also don't use MS GitHub -style merges, I find them inferior. (I also don't use MS GitHub, but that's for another reason.) I think they try to make merges the actual unit of change, which is stupid, because that is what a commit is for. To me merges are about semantic grouping of commits, i.e. maintaining a tree of commits representing the logical evolution of the code.

Yes the staging area is exactly designed for this approach and I don't like people telling me I'm holding it wrong and don't need it. To use a metaphor, I think the staging area is like my desk were I'm producing stuff (I'm not producing code, I'm producing changes). Committing is about having produced a complete opus and then cleaning the desk. Cleaning isn't seen as annoying, it is important for the mind to process completing/validating and then starting afresh. Stashing is in this metaphor about switching to an alternate desk. This is different from putting the opus aside and having also a clean desk. (I think that is what Jujutsu wants you to do?) Having the staging-area/stash different from commits is a feature, the fact that the stash is the same storage-wise is an implementation detail.

By default, the top (current) commit acts like a staging area and in fact is implemented as a dirty working tree in git.

Commits start live without a description, and can’t be pushed without adding one. jj commit names the current commit and creates a new empty, unnamed commit on top, which effectively is precisely git’s behaviour.

I implore you to try it. In practice the distinction just doesn’t matter, except it’s one less concept to keep track of, and jj allows you to make up other workflows if you want.

Sure, sometimes I want to work with a WIP commit and then I'm just doing that in git.

I think functionally of the stage is about the UI, so keeping it separate is kind of the point. I find that useful, as I can use both approaches, not sure how its better if jj can just use one?

> to ask why they do this.

This was what I was trying to explain. To me the feature is needing to manually mark every line to be committed. If I need to split the commit I'm already not paying that much attention.

jj’s workflow isn’t about being careless with commits—it’s about time-shifting that care to when it’s most convenient. You’d split the commit later for the same reasons you wouldn’t want your text editor to force manually marking each line to save to disk.

>A commit is really about, well, committing that these are exactly the right lines of code I intended to write.

That would be a ‘change’ in jj. A commit in jj is more like SQL than git; it's the end of a transaction, not a value judgement.

Thanks, I was writing about git, though.

> I also don't use MS GitHub -style merges, I find them inferior. (I also don't use MS GitHub, but that's for another reason.) I think they try to make merges the actual unit of change, which is stupid, because that is what a commit is for. To me merges are about semantic grouping of commits, i.e. maintaining a tree of commits representing the logical evolution of the code.

Thank you for going into details, you helped me understand a few more details.

Let me describe how I think about it and why it might possibly conflict with your ideas.

I think the best way to describe it is as a series of approvals, each one being more important than the previous one.

The absolute lowest level of approval, writing the file to disk. You've made some changes and you're happy enough with them to at least save them in case you have a power outage or something.

The next level of approval is committing to your local git repo. This is code you're fairly confident you want later, even if it might not be perfect yet.

The next level is pushing your branch to the origin repo. Now you're saying that this is code you're willing to let other people look at.

The last level is merging this code into main/trunk/whatever. This is the final level of approval, this code passes all of our checks, it shouldn't need any more improvement.

Given this system, adding another level in there, for staging commits, feels pretty unnecessary.

I agree that merge commits tend to make for ugly git history, but I don't think that's particularly inherent to any of these systems of code integration, it's more a function of how much the developers care about the git log.

> change commits, but this has a danger of creating a version that was never there or mixing history,

I'm not sure what the benefit here is. I think I've basically ended up in a situation where I treat 'git commit' the same way I treated "save file" 20 years ago. My local commits/saves/edits aren't important, what's meaningful is the final unit of change I'm sending to the remote, and that unit needs to be deliberately constructed somehow. Whether that involves rebasing or amending or careful usage of git stage, it's an artificial unit you're creating just as much as the actual code changes.

> What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready.

I was extremely hostile to this aspect of jj too, but I've settled on a workflow where @ (i.e. the change/commit referring to the working copy) is always the same, named ".WIP: …", and as such is clearly never supposed to break out of the local system, and can never accidentally get pushed down the log. (..my jj workflow is just blatantly copying my git workflow (with the same-name shell aliases/helpers even), but even with said git emulation I'd say it's nicer than git itself)

Still may be weird/undesired to have the local repo preserve the changes (especially annoying if it happens to find an unignored build artifact, though there is a size limit for automatic tracking by default), but it's also rather neat that you can dig out your old deleted printf debugging or whatnot later on if you wanted to.

If you leave the WIP head change blank, i.e. don't give it a description at all, then JJ will block you from pushing it unless you pass a specific flag, which is useful for sanity checking this sort of stuff.

You might be able to configure JJ to also block commits with certain descriptions as well, which might be useful in your case.

I specifically have the WIP head description include the name of bookmark that it's attached to, if any (emulating git's non-detached head), so can't leave it empty (and generally wouldn't want to, for easy way to identify it, esp. with multiple workspaces).

Some push blocker for certain commit name patterns would make sense to look into.

Should be simple enough, but look into trailers; the language already supports key-value maps in the commit description.

You indeed can: https://jj-vcs.github.io/jj/latest/config/#set-of-private-co...

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready.

jj doesn't have the concept of a non-committed file.

instead you don't track the HEAD as the tip of the branch (@ in jj), you track HEAD^ (jj: @-) or something earlier and since jj rebase isn't dumb as a rock you can relatively easily keep the working set of changes (as in, multiple commits/WIP branches; not necessarily the index or the working copy) on top of what you are pushing and squash or advance the branch (bookmark).

I'm reiterating because it's a very important and super confusing for advanced git users: there is no uncommitted state in jj and yes, it does make sense, but you need to stop thinking in git.

Can't this be a security risk as there might be secrets that should never be recorded by jj (You can probably configure this, but I want my software to only do what I tell it to, not do everything until I tell it not to.)

How does that work in practice, is there a daemon running constantly and monitoring? How does that interact with other users and changes from other computers?

Every jj invocation stores a snapshot before doing anything else - thus anytime you run jj, you tell it to store a snapshot in the local repo.

I don't see a problem with secrets TBH. .gitignore is respected if that's what you have in mind. Otherwise store your secrets out of tree (you probably should with git too, anyway.)

Right now I can mess around like I want, because I am in charge what gets tracked, I need to specify it explicitly. This would loose that.

this is not as important as you're used to. I've been there, I've used git since early 2010s and yes autostaging was preposterous at first. in practice, it's barely relevant: the workflow changes from 'I pick what is tracked' to 'I pick what is pushed'.

I'm not sure if objects won't get pushed accidentally. I would place the boundary at object creation not upload. Also you might copy the repo, then you also might leak an accidentally created object.

to each their own. you can argue in theory, in practice it is just not a problem.

You know your evangelists have gone haywire when they're explaining that your requirements are wrong instead of listening.

I don't think that's a fair characterization.

It's more that there isn't really a big difference between the workflow of

    # you're on
      staging area
    @ commit A
    # make some untracked changes and console logs you don't wanna commit
    git add -p && git commit # select only what you want

    # you're on
    @ empty commit 
    | commit A
    # make some local changes (which are tracked in @)
    jj commit -i # select only what you want

You're still "in charge what gets tracked" if you treat the last @ commit as your local playground, exactly the same as the staging area. The only difference is that you can use exactly the same tools to manipulate your "staging area" as other commits. The only difference being that you can manipulate your staging area with the same tools as any other commit.

Wait, what happens when there is a multi-GB file laying around and a jj command is being invoked? Does it start to scan it or is there some threshold. What does it do with cyclic hard-/sym-links?

There's a (configurable, easily bypassed) limit for newly created file size to catch that common mistake.

I'm far from being an evangelist. I'm trying out jj in one repo out of several and it's far from perfect - but it is useful though, and it does make sense. The requirement of being able to not commit everything by default is simply not necessary from a logical standpoint; if anything, it is itself evangelism that the git way is the right way. The truth is both work just fine, which has been my point all along.

Secrets and client data. Regulated environments are very serious about client data. They can't go into source control either.

You can't change example.com/foo to point to example.com/baz and have it exist in source control. So to make the change you have to ignore every file that contains that string, test, then unignore. Or you have to make sure to absolutely remove every reference you've added to the merkle tree. Or you have to completely nuke your source control database after testing.

If you buy a used laptop hard drive from a remote worker at $BIG_REGULATED_CO because you want to find exploits, you're probably happier if they run jujutso than git because there will be a higher probability of finding secrets, client info, and other things that are forbidden from going into source control.

> Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream.

This makes sense to me as a longtime Mercurial user. In short, by default, when you push a commit, it becomes public and therefore immutable [1].

Other awesome Mercurial features that appear in JJ are revsets [2], filesets [3] and templates [4]. Looking forward to giving JJ a try.

[1]: https://wiki.mercurial-scm.org/ChangesetEvolution

[2]: https://jj-vcs.github.io/jj/latest/revsets/

[3]: https://jj-vcs.github.io/jj/latest/filesets/

[4]: https://jj-vcs.github.io/jj/latest/templates/

> I'm confused what this is?

jj is a version control system. It is backend-agnostic. The most common backend is a git one, because git is so popular. This allows you to use jj on a git repository, allowing for individuals to adopt it without forcing their teammates to.

> Is it just a git frontend for people who are confused by git?

I used git since before github existed. I considered myself a git lover before I found jj. I will not be going back to git.

The thing is, jj is both simpler and more powerful than git, at the same time. People who are confused by git may like its simplicity, but I like its power.

You already got some replies on this one, so I'll leave that to them :)

This is an understandable misunderstanding. The right way to think of it is "the index is also a commit." A common way of working with jj is to do something like this:

Imagine I am working on adding some feature x to my codebase. I'll first make a change, and give it a description:

   jj new -m "working on feature x" trunk
  Working copy  (@) now at: lqqlysul c6756b49 (empty) working on feature x
  Parent commit (@-)      : ylnywzlx 8098b38d trunk | (empty) foo

Now I will make a new empty change on top of that:

   jj new
  Working copy  (@) now at: pxrvoron c823d73a (empty) (no description set)
  Parent commit (@-)      : lqqlysul c6756b49 (empty) working on feature x

Now, @- is the change that I intend to push publicly, but @ is my index. Say I add foo.rs:

   touch foo.rs

Now, when I run `jj status`, jj takes a snapshot, and it now lives in @:

   jj st
  Working copy changes:
  A foo.rs
  Working copy  (@) : pxrvoron ba7ad8c6 (no description set)
  Parent commit (@-): lqqlysul c6756b49 (empty) working on feature x

We can see the diff here with `jj diff`:

   jj diff
  Added regular file foo.rs:
      (empty)

So, let's say I'm happy with its contents. I want to stage it into my final commit. I can do this with `jj squash`, which by default takes all the diff of @ and puts it into @-:

   jj squash
  Working copy  (@) now at: pxkqmsww 9f7e1ef2 (empty) (no description set)
  Parent commit (@-)      : lqqlysul 41dc1531 working on feature x

Now that change is in @- instead of @. we can see that by passing -r (for revision) to `jj diff`:

   jj diff -r @-
  Added regular file foo.rs:
      (empty)

I don't have to move the whole change; I can do the same thing as git add -p by using jj squash -i, and only move the portions of the diff.

What's the advantage here? Well, because the index is just a commit, I can use any tools that I use on commits on the index. There's nothing like `git reset` needing to have `--hard` vs `--soft` vs `--mixed` to deal with index behavior: everything is in a commit, so everything acts consistently.

jj makes it very trivial to carve up commits into exactly what you want. It is far easier and more powerful than using the index for the same purpose.

> The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking.

IMHO, commit pollution is more due to the pull request workflow than git itself, though I do think that git doesn't do that much to help you. jj can help with this kind of thing, but also on some level, it can only do so much.

I want to appreciate this cool-sounding new tool, but everything you've said sounds exactly the same as using git rebase, what am I missing?

Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks. And it sucks even worse when you screw up the conflict resolution halfway through and have to start over from scratch.

Rebases also don't play nicely with stacked branches. Branches based off your original changes don't get rewritten to be on top of the rebased change, so now multiple rebases are in your future.

It turns out that basically none of the rebase friction most people experience is necessary in practice. Rebases can be automatic, implicit, and conflicts can be fixed at your leisure and in whatever order that you feel is best.

jj also has a ton of other powers, but you asked about rebase :)

> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks

You can use git commit --fixup to record what you want to change in an earlier commit.

> start over from scratch

rerere

> Branches based off your original changes don't get rewritten

As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.

> You can use git commit --fixup to record what you want to change in an earlier commit.

jj just does it correctly by default.

> rerere

jj just does it correctly by default.

> As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.

jj just does it correctly by default.

defaults matter.

>> git commit --fixup

> jj just does it correctly by default.

JJ adds changes to random old commits instead of the newest one? Yikes.

> rerere by default

Takes space and time.

> --update-refs by default

Maybe sensible, don't need it most of the time.

> JJ adds changes to random old commits instead of the newest one? Yikes.

jj adds changes to the current commit, which is the staging area, which is the index, which is the working copy. I get you don't like it, no need to be an ass about it, but denying that it works is just that, denial.

> > rerere by default

> Takes space and time.

doesn't take my time. I'll take it.

> > --update-refs by default

> Maybe sensible, don't need it most of the time.

No reason to waste time thinking when it's needed.

> no need to be an ass about it

That wasn't what I meant, git --fixup is for changing earlier commits, you answered as if it didn't that's what I wanted to point out. (I tried to be sarcastic, because it was obvious that you didn't mean that.)

>> Maybe sensible, don't need it most of the time.

As in I want the opposite behaviour most of the time. That's why that is the default.

Yes, there are a million weird band-aids that git has grown over time. Some of them work better than others.

Or we could just not have the problems to begin with.

There are some later additions like git switch, but git rebase and git commit ain't one.

`--update-refs` was added in 2.38, in 2022. `--fixup` was added in 1.7.3. Like I said, git has grown additional features and workarounds. Knowing all of them is a lot of work.

You can do everything with git rebase, the question is how much pain are you willing to tolerate. If you've ever solved the same conflict twice and/or are aware of git rerere, you should try jj.

The impression I get from all the jj writeups is that the devs said "rebases are really cool, we should move heaven and earth to make them even cooler".

Reply on news.ycombinator.com