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

451–460 of 517 posts

Re: jj – the CLI for Jujutsu

#451

Post by adastra22 »

Diggsey wrote: post #44
jdkoeck wrote: post #27

Earlier quoted context omitted.

Wow, that’s a total deal breaker to me. Using git may require a complex mental model, but at least it’s not doing anything I didn’t ask for.

You would have had to run `jj edit` in order for this to happen, so I think it's a stretch to say you didn't ask for the edit? This is the main difference though: in git files can be `staged`, `unstaged` or `committed`, so at any one time there are 3 entire snapshots of the repo "active". In `jj` there is only one kind of snapshot (a change) and only one is "active" (the current working directory). When you make chan…

I really, REALLY wish jj picked a different subcommand name for that than 'jj new'.

Re: jj – the CLI for Jujutsu

#452

Post by rstuart4133 »

jancsika wrote: post #308

I was going to write a big long comment, but honestly it boils down to this: Whatever git's practical benefits over SVN and CVS back in the day (and I can go into the weeds as a user if someone wants that), git was the DVCS that took over from the centralized VCS's of that era. There is nothing in jj, pijul, or Bram Cohen's thing that is anywhere near as dramatic a quality of life improvement as going from VCS to any…

There is some truth to that, but to give a different perspective ...

A long, long time ago, back when VCS's were novel enough to be of academic interest, I read numerous papers describing what these VCS's could be. They talked in terms of change sets, and applying them like a calculus to source code. In the meantime those of us writing code people actually used were using sccs and rcs, or if you were really unlucky Visual SourceSafe. To us in the trenches those academics were dreamers in ivory towers.

With the passage of time we got new VCS that gradually knocked the rough edges off thoase early ones. svn gave us atomic commits, hg gave us a distributed VCS, git gave us that plus speed. But none came close to realising the dreams of those early academics. It seemed like it was an impossible dream. But then along came jj ... and those dreams were realised.

Re: jj – the CLI for Jujutsu

#453

Post by cornstalks »

skydhash wrote: post #436
Balinares wrote: post #423

Earlier quoted context omitted.

In sort of the same way juggling apples is better than juggling hand grenades: it's mostly the same in the simple cases, but once you start doing the really fancy stuff, one of the two will get you a lot fewer messy explosions. (Your question is not dumb, BTW. The pithy answer is: UX matters , but it does so in ways that can be hard to convey since it's about the amount of cognition you need to put in a given thing t…

You have to put a lot of effort to mess up a git repo. So I'm not seeing the allusion to hand grenades.

I’ve done it multiple times without much effort. Or skill. Really it was a skill issue and I tried things that I thought would work but apparently don’t.

I screwed up jj a few times while picking it up, but jj’s undo command made that trivial to go back and try again. With git? I know a lot of things can be undone but I can never remember how to do it!

Re: jj – the CLI for Jujutsu

#454

Post by Aperocky »

chriswarbo wrote: post #301
Aperocky wrote: post #264

With agents, my go to is now have multiple of the same repository and each agents must work on a separate one. Preventing dirty workspace by solving the co-work problem to start with. merges are much more trivial than trying to make agents remember which branch or which folder it is supposed to work on. Disk space is cheaper than mental anguish and token usage.

https://git-scm.com/docs/git-worktree

rare case of feature bloat for git. Still completely optional, thank god linus.

Re: jj – the CLI for Jujutsu

#455

Post by saghm »

nightski wrote: post #431
saghm wrote: post #409

Earlier quoted context omitted.

"Just don't accidentally do things wrong" is also the way to avoid null pointer errors, type mismatches in dynamically typed languages, UB in C/C++. It works, until it doesn't, and in practice that happens pretty quickly. Personally, I like things that have proper safety checks.

Except it's not an unrecoverable error. If you do it all it does is add that file to the working index. No commits are made and no harm is done. So no, I do not feel it's the same as a null pointer exception or type mismatch.

> If you do it all it does is add that file to the working index.

No, that's not at all what it's doing!

    git init
    touch foo.txt
    git commit -m 'empty foo.txt'
    echo something >> foo.txt
    git diff --stat # Shows one line added to foo.txt
    git checkout foo.xt
    git diff --stat # empty output; no changes!
It removes changes that are not yet checked in. You can only get them back by going into the reflog (which is pretty much identical to the situation described with `jj edit` at the beginning of this thread; `jj op log` will let you get them back fine).

edit: Actually, I was wrong; the changes will NOT be in the reflog because they were never checked in. It's fully destructive; you've lost the changes and don't have any way of getting them back through git. This is strictly worse than anything possible with `jj edit`, and even when making this point I didn't realize how bad it was, and clearly neither did anyone defending it.

The fact that there have already been two instances of defending git's behavior without even understanding what it's doing with this command is exactly my point. It's not your fault; the command is unintuitive, and that's my entire point. How many times should it take for people to try to explain what's happening incorrectly before we accept this?

Re: jj – the CLI for Jujutsu

#456

Post by em-bee »

sfink wrote: post #284
shermantanktop wrote: post #182

Earlier quoted context omitted.

This is me! I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion. Hence I have multiple workspaces, and I shelve changes a lot (IntelliJ. I end up with dirty repos too and that can be painful to cherry-pick from. Sometimes I just create a git patch so I can squirrel the diffs into…

I'm about the same. jj is kind of perfect for that. Example: # I've finished something significant! Carve it out from the working "change" as its own commit. `jj commit --interactive` # aka `jj commit -i` or `jj split`, depending on how you prefer to think of it: making a commit for some work, or splitting a separate commit out of the working change. # Oops, missed a piece. `jj squash --interactive` # aka `jj squash…

# I've finished something significant! Carve it out from the working "change" as its own commit.

    git add -p
    git commit
# Oops, missed a piece.

    git add -p
    git commit --amend
# Let me look at what's left.

    git diff
# Oh right, I had started working on something else. I could just leave it in the working change, but let me separate it out into its own commit even though it's unfinished, since I can always add pieces to it later.

    git add -p
    git commit
# Wait, no, I kind of want it to come before that thing I finished up. i didn't mess up, this is standard procedure

    git rebase -i  # put commits into the desired order.
# I also have some logging code I don't need anymore. Let me discard it.

don't know what jj does here

    edit files
or

    git revert -p
# Do some more work. I have some additions to that part I thought was done.

    git add -p
    git commit
    git rebase -i  # choose the right place and then tell git to squash into the parent
# And some additions to that other part.

    git add -p
    git commit
    git rebase -i  # as above
you list a number of different commands that i do in git always with the same sequence of commands. i don't see how jj makes those examples any easier. it looks like maybe they help you get away with not understanding how git works, by instead giving you more commands that do specifically what you want.

Re: jj – the CLI for Jujutsu

#459

Post by baq »

em-bee wrote: post #457
baq wrote: post #260

Earlier quoted context omitted.

git add -p doesn't create a commit.

then create one when you are done adding?

why bother? jj does it automatically and gives tools to work with such commits, no point to force this on yourself with git

Re: jj – the CLI for Jujutsu

#460

Post by rs545837 »

bikelang wrote: post #354
rs545837 wrote: post #318

Earlier quoted context omitted.

You could agree that the PR is the meaningful unit for shipping, but push back gently that for agents working in parallel, the commit/changeset level matters more than it used to because agents don't coordinate the way humans do. Multiple agents touching the same repo need finer-grained units of change than "the whole PR."

Could you elaborate a bit more on this? Curious what your workflow looks like. Is this multiple agents running on the same feature/refactor/whatever unit of work? For concurrent but divergent work I just use a git worktree per feature. And I think I only ever have a single agent (with whatever subagents it spins up) per unit of work.

Think two agents working on the same codebase at the same time. Agent A is refactoring the auth module, Agent B is adding a new API endpoint that imports from auth. Separate worktrees, separate branches, but they're touching overlapping code.

ingle agent per feature works great today. But as agents get faster and cheaper, the bottleneck shifts to, how many agents can work on one repo simultaneously without stepping on each other.

Post reply on HN