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

71–80 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#71

Post by bsder »

sfink wrote: post #52

I've been using jj for a month, coming from mercurial. I have settled into a usage pattern slightly different than the article describes, so that all of those `jj edit` commands made me a little itchy. I prefer to nearly always use a separate @ commit to hold any changes I make. The mental model is that there's a graph of commits, and then @ is an auto-updated commit to hold any changes I make in an editor or whateve…

> It makes jj modal, and one of the things I most appreciate about jj is that it is not modal, you don't have a separate staging area or stash or anything, it's always in the same consistent state where you can do the same set of things.

Staging and stash are modal--YES! I'm going to steal this.

I've been trying (and failing) to explain what I hate about staging and stash for years and this explains the issue so succinctly.

Re: Jujutsu VCS: Introduction and patterns

#72

Post by cube2222 »

pkulak wrote: post #70
12_throw_away wrote: post #23

Earlier quoted context omitted.

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a…

I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see…

Can confirm this.

I’ve also configured my jj to use the goland/intellij terminal command for diff viewing and conflict resolution, so I can still use the (imo great) visual tooling built into JetBrains IDEs.

Re: Jujutsu VCS: Introduction and patterns

#73

Post by pkulak »

dragonwriter wrote: post #68
pkulak wrote: post #67

>> Changes in jj can be marked with bookmarks (what jj calls branches), JJ actually calls its bookmarks "bookmarks". Maybe these two words got accidentally flipped?

No, the English structure " ... what jj calls " just has an annoying semantic ambiguity, and can either mean " is the name used by jj for the thing that is more commonly referred to as " or "the thing more generally called is referred to as by jj", which is expected to be resolved by the reader on the basis of whether or is the generic term they are familiar with.

Oh, you're right, I didn't read it in my head like that.

Re: Jujutsu VCS: Introduction and patterns

#74

Post by gcr »

I mentioned this on previous discussion recently, but I use jj for all my projects on github! It's really useful for my sort of workflow: chains of commits with easily-editable history. If you make a change back in time, you edit the previous commit (which puts you in a state similar to git's detached head), and any edits you make there are automatically carried forward (rebased) onto descendants. It feels way more natural, especially for newer users.

The killer feature that I love the most is a small one, but it's that commit messages can be made ahead of time rather than after-the-fact. So I can sit down at my desk, say

    jj new -m "Work on XYZ feature"
then edit my code in the editor. When I'm finished, I move on to the next commit:

    jj new -m "Working on UVW feature"
No more "oh no I accidentally started touching code and forgot to commit my work, so now I have to manually split two git commits;" it's a small way that the tooling encourages you to be intentional about your engineering philosophy.

The fact that jj snapshots the working tree on every command is a mixed blessing. It's nice and fast and so I do prefer it, but there have been times that I've been bit by accidentally adding my python virtualenv into repository history. Luckily it's easy to undo.

    jj log ./venv # see which change added it
    jj edit change-id
    echo venv >> .gitignore
    rm -r ./venv # or jj file untrack ./venv
    jj edit whichever-change-you-were-on

Re: Jujutsu VCS: Introduction and patterns

#75

Post by sunshowers »

saghm wrote: post #49
sunshowers wrote: post #48

Earlier quoted context omitted.

(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.

Yeah. In Mercurial the set of immutable heads is state that's stored in the repository. In Jujutsu this is done via a revset, which is a really clever approach.

Re: Jujutsu VCS: Introduction and patterns

#76

Post by sunshowers »

justinpombrio wrote: post #59
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…

> 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" The default for what's immutable is actually `main` together with untracked remote branches [1]. I agree that what you suggested should be the default though. You can change it by adding this line to your `jj` config: [revset-aliases]…

So the reason this isn't the default is that often you'll be amending and force pushing tracked remote bookmarks.

There are several use cases for bookmarks/branches that are a bit muddled, which suggests a deeper theory of bookmarks that should inform the user experience. One of the Jujutsu developers had a neat post on the Discord [1] talking about how "bookmarks must be data-flow edges: think mutability, variance, polarity, etc." This sounds generally right to me, though turning this into a fleshed-out theory and then into a good user experience is a bit of a daunting challenge.

[1] https://discord.com/channels/968932220549103686/132711440887...

Re: Jujutsu VCS: Introduction and patterns

#77

Post by gcr »

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)?

Jj lets you edit:

- History you haven't pushed yet, or

- Bookmarks that you're tracking (meaning you're actively working on these branches), except "main"

History behind "main" or behind any untracked remote bookmark is immutable by default.

If you want to move "main" or any remote bookmark to a commit that isn't a descendant, you have to use `--allow-backwards`. If you want to edit one of these commits, you can use `--ignore-immutable`. Using either of these options is like a `push -f` in git terminology.

Re: Jujutsu VCS: Introduction and patterns

#78

Post by gcr »

diego898 wrote: post #62
cube2222 wrote: post #47

Earlier quoted context omitted.

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…

Thanks that makes sense - just feels weird to go from years of “be very careful rewriting history with git, especially at work” to jj rewriting everything all the time - can’t shake the feeling there’s a clash somewhere waiting to happen

As long as you don't use `--allow-backward` or `--ignore-immutable`, and as long as everyone sticks to their own feature branches, this shouldn't be possible.

The operation log makes jj quite safe. There's a command to restore the entire working copy + history to an earlier state in case you screw something up. Even this operation log is itself versioned, so you can undo the undo if you screwed the undo up, ad infinitum. :)

Re: Jujutsu VCS: Introduction and patterns

#79

Post by sunshowers »

sfink wrote: post #52

I've been using jj for a month, coming from mercurial. I have settled into a usage pattern slightly different than the article describes, so that all of those `jj edit` commands made me a little itchy. I prefer to nearly always use a separate @ commit to hold any changes I make. The mental model is that there's a graph of commits, and then @ is an auto-updated commit to hold any changes I make in an editor or whateve…

Yeah, I agree with this. I definitely prefer `jj new` and then squashing changes -- it also means I can see what changes I just made with `jj diff`.

Re: Jujutsu VCS: Introduction and patterns

#80

Post by ashenke »

gcr wrote: post #78
diego898 wrote: post #62

Earlier quoted context omitted.

Thanks that makes sense - just feels weird to go from years of “be very careful rewriting history with git, especially at work” to jj rewriting everything all the time - can’t shake the feeling there’s a clash somewhere waiting to happen

As long as you don't use `--allow-backward` or `--ignore-immutable`, and as long as everyone sticks to their own feature branches, this shouldn't be possible. The operation log makes jj quite safe. There's a command to restore the entire working copy + history to an earlier state in case you screw something up. Even this operation log is itself versioned, so you can undo the undo if you screwed the undo up, ad infini…

For every feature we usually have two developers working on it, one frontend and one backend, working on the same feature branch. Would Jujitsu cause a problem in this context?
Post reply on HN