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

Jujutsu VCS: Introduction and patterns

kubamartin.com

Post reply on HN
Print view View original

41–50 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#41

Post by steveklabnik »

hinkley wrote: post #38

The fact that jj doesn’t tell you what files have changed until you start a new commit is holding up my plans to use it. It’s frustrating for me and I imagine it would create tech support questions if I made others use it if it’s to replace git it needs some further ergonomics refinement.

I am not 100% sure what behavior you're talking about, but if it's that `jj` doesn't snapshot until you run a `jj` command, you can add watchman, and then it will do so on every filesystem change https://jj-vcs.github.io/jj/latest/config/#watchman

Otherwise, jj status will show you the current changes at any time.

Re: Jujutsu VCS: Introduction and patterns

#42

Post by sunshowers »

keybored wrote: post #36
theLiminator wrote: post #21

Earlier quoted context omitted.

I think the main problem it solves is stacking https://www.stacking.dev/

That’s a problem created by GitHub or people unable to think outside of the GitHub model. It would make more sense to solve that problem through a review tool. For what it’s worth from what I’ve read about JJ: it’s a better VCS frontend overall.

There are two distinct but related issues here: GitHub's terrible support for stacked PRs, and Git's `rebase -i` user interface to manage them which is quite bad. Jujutsu fixes the latter.

I maintain a fork of a tool called `spr` which comes as close to fixing the former as GH allows. It has a number of limitations, though. https://github.com/sunshowers/spr

Re: Jujutsu VCS: Introduction and patterns

#43

Post by saghm »

cupofjoakim wrote: post #3

I think I'm at risk of sounding like a broken record here. I've read about jj many times now but i'm still confused as to what problem it actually solves. I get the same feeling as when some dude wants to sell me on using vim as my primary code editor - arguments are there but it doesn't really solve an issue. I'll go over to jj when that's the primary tool for the job, or when I can see something that beats the git…

I've switched over to using it pretty much exclusively over git directly. While there are a number of minor things that I prefer about it over git, these are the two main ones for me personally:

* If I don't pass `--allow-immutable`, trying to run a history-rewriting command will immediately fail if it would touch a commit that's present on a tracked branch from a remote. When using git directly, it's way easier to accidentally make changes during a rebase that conflict with remotes and then requires me to go back and fix it when I can't do a fast forward to sync the changes *Conflicts are part of the state of individual commits rather than a property of an ongoing operation. When an operation produces a conflict in one or more commits, I can still do whatever development (or make version control changes) on any of the other commits. I'm free to fix the conflicts in any order I want, or fix some of them now and worry about the others later, which is much more intuitive to me than using `rerere` to achieve something similar with git directly. I could even imagine a scenario where I might want to push up conflicts that come from attempting to merge my own changes with ones made in parallel from someone else so that they could resolve some of them if I wasn't confident in my understanding of the changes they made, although this isn't something that I've run into yet.

A lot of this hinges on the ways I personally use git; I tend to commit often and not worry about making sure the history is clean or the commit messages are perfect until I actually want to merge them, and I absolutely loathe merge commits, so this ends up meaning I rebase a _lot_. The benefits I mentioned probably wouldn't seem very significant if you don't work on shared codebases often or if you use git in a way that you rarely rebase, but because these feature solve concrete annoyances I'd run into quite often with git, the quality of life improvement feels massive to me.

Re: Jujutsu VCS: Introduction and patterns

#44

Post by necauqua »

hinkley wrote: post #38

The fact that jj doesn’t tell you what files have changed until you start a new commit is holding up my plans to use it. It’s frustrating for me and I imagine it would create tech support questions if I made others use it if it’s to replace git it needs some further ergonomics refinement.

It's `jj status`?.

Re: Jujutsu VCS: Introduction and patterns

#45

Post by diego898 »

bkolobara wrote: post #19

I have used jj for about one month on a project with a colocated git repo. So far, I enjoy it a lot. Previously I would have a bunch of 'wip', 'fix typo' commits, but my commit history got much cleaner with jj. It's very easy to jump to old changes and apply fixes right in the place they belong. All changes + tests are now committed as one unit. I would never bother to do it in git, but because it's so easy now, I do…

How does this work with a shared remote branch? I know in git when you alter your history you can do a `git push --force-with-lease` as a safer `--force` - do you have to do this frequently with jj "rewriting history" (from a git perspective)?

Re: Jujutsu VCS: Introduction and patterns

#46

Post by saghm »

password4321 wrote: post #13
dartos wrote: post #8

Earlier quoted context omitted.

I switched from git to jj a few months ago, so I may have some insight. I used it at work, where everyone used git, and there were 0 issues. What I really like about it is how changes are sort of soft committed right away and, when I checkout a different branch or change, I don’t need to stash my changes and remember the stack of stashes. Rebasing and merging feel a little easier, but that might just be because “ours…

> I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works) Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?

One of the main innovations in how `jj` works (in my opinion at least) is that has a concept of "immutability" for commits, which if I recall correctly is configurable with an arbitrary filter in the config, but the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable". When you run a command to try to change any immutable commits, it will refuse unless you manually opt-in with `--allow-immutable`. This makes it super easy to clean up the commit history from local development without having to worry about accidentally putting stuff in a state where there will be conflicts when you try to sync the changes with a remote later.

I think what they're the parent commenter is referring is being able to make changes to older "mutable" commits without having to do a rebase. I'm not sure I find the description of this as being similar to an "automatic rebase" super helpful personally; the way I'd personally describe it is being able to do the equivalent of "git commit --amend" on any commit with a built-in safety check to prevent this from accidentally modifying commits pushed to remote branches that you need to explicitly override if you want to ignore it.

Re: Jujutsu VCS: Introduction and patterns

#47

Post by cube2222 »

diego898 wrote: post #45
bkolobara wrote: post #19

I have used jj for about one month on a project with a colocated git repo. So far, I enjoy it a lot. Previously I would have a bunch of 'wip', 'fix typo' commits, but my commit history got much cleaner with jj. It's very easy to jump to old changes and apply fixes right in the place they belong. All changes + tests are now committed as one unit. I would never bother to do it in git, but because it's so easy now, I do…

How does this work with a shared remote branch? I know in git when you alter your history you can do a `git push --force-with-lease` as a safer `--force` - do you have to do this frequently with jj "rewriting history" (from a git perspective)?

Yeah, `jj git push` acts as an equivalent (according to my experience and understanding) to `git push --force-with-lease`, always.

You don't have to pass an explicit --force, nor an explicit lease-related argument. As you say, rewriting the commits underlying changes happens frequently, so this would otherwise be pretty annoying.

There's also `jj git push --dry-run` to preview which branches would be updated in what way.

Re: Jujutsu VCS: Introduction and patterns

#48

Post by sunshowers »

saghm wrote: post #46
password4321 wrote: post #13

Earlier quoted context omitted.

> I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works) Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?

One of the main innovations in how `jj` works (in my opinion at least) is that has a concept of "immutability" for commits, which if I recall correctly is configurable with an arbitrary filter in the config, but the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable". When you run a command…

(Commit mutability separation, like many of jj's other features, was originally implemented in Mercurial.)

Re: Jujutsu VCS: Introduction and patterns

#49

Post by saghm »

sunshowers wrote: post #48
saghm wrote: post #46

Earlier quoted context omitted.

One of the main innovations in how `jj` works (in my opinion at least) is that has a concept of "immutability" for commits, which if I recall correctly is configurable with an arbitrary filter in the config, but the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable". When you run a command…

(Commit mutability separation, like many of jj's other features, was originally implemented in Mercurial.)

Good to know! I guess the "innovative" part was being able to apply these semantics on top of git without breaking compatibility.

Re: Jujutsu VCS: Introduction and patterns

#50

Post by ilyagr »

hinkley wrote: post #40
gechr wrote: post #26

Earlier quoted context omitted.

Although it is currently undocumented, since v0.21.0 you can make `--edit` the default by adding the following to your configuration: [ui.movement] edit = true Ref: https://github.com/jj-vcs/jj/pull/4283

The config file needs a lot of love. As does the help. If you clone the repo there’s a bunch of documentation and example files, but if you install jj, those do not exist.

Each release comes with a file with all the help, for example:

https://github.com/jj-vcs/jj/releases/download/v0.25.0/jj-v0...

In theory, packagers could put these docs somewhere. I'm not sure what the best way is to make it convenient to use.

Also, I'm not sure about jj v0.25, but in the upcoming (probably tomorrow) 0.26, you can get a lot of docs by doing e.g. `jj help -k config`. Ironically, this fact is currently somewhat under-documented. `jj help` just says at the end:

`'jj help --help' lists available keywords. Use 'jj help -k' to show help for one of these keywords.`

Post reply on HN