martinvonz

Thanks for the detailed comment.

My target audience were the people at the conference, who are mostly long-term jj users. The topic was "Jujutsu at Google: Architecture and future plans", i.e. explaining how it works and what our plans are at Google. I'm mentioning this because I think what you're suggesting is for a different presentation, more explaining what the advantages of Jujutsu at Google are rather than how it works. My goal was not to sell the solution to this audience because they're presumably already sold on it.

Sorry if this was obvious to you and you're saying that part of my problem was that I should have chosen a different topic and/or target audience (focusing more on potential new users, perhaps).

Thanks!

The presentation was mainly for the audience that was present at the conference, which was mainly people who have used jj for a relatively long time, so I think part of the problem is just a mismatch between audiences there and on YouTube.

I agree about being more exciting. Not sure how to improve that :P I drink too much coffee all the time that I don't notice any difference. Harder drugs, perhaps :)

Putting less details on the slides is something very actionable. Thanks.

> Also, present things that you are passionate about if you want to make people care about your presentation.

Haha, this topic is something I'm very passionate about. That's how I look when I'm excited :)

Thanks for the link. I went through it but I'm not sure what it's telling me to change. Can you elaborate? If it's "be more engaging", i think is unfortunately going to be hard to improve because this is just how i am.

That won't update sibling branches

> jj does this for performance reasons. They don't want to perform a full checkout for every rebase action.

It's true that `jj fix` can be faster by not touching the working copy, but we also want a `jj run` command for the linter feature (https://github.com/jj-vcs/jj/issues/1869). It's just not done yet.

j2kun seems to be a googler so I don't think so, but it's true that Facebook also went with Mercurial. I suspect it was for similar reasons.

Yes, that's correct. Another reason was that Mercurial is easier to customize because it's written in Python so we could sometimes just replace whatever we needed without needing much changes from Mercurial itself.

Yet another reason is that the .git directory is considered a documented API and several other tools and libraries depend on it (e.g. JGit and libgit2). So any new features for Google would need to be made to those tools too if we wanted things built on them to work.

We also consider Mercurial to have better UX.

I think you misunderstood. I didn't ask for their name. Luckily the author didn't seem to misunderstand.

As for information about me, you can search the internet for my username. Let me know if you don't find anything and I can try to help. I'm not going to share information about others on the Discord server.

Thanks for working on this project!

It was mentioned on the JJ Discord server that there doesn't seem to be any information available about who you are. Especially since the project seems to be closed-source, perhaps you could share some information about who you are in order to build trust.

I hope you understand. I think users may hesitate to download and install the application without knowing anything about its publisher.

Do you mean if jj has separate author and committer timestamps? Yes, we simply followed Git there. I didn't really question it. There has been some discussion about simplifying it to just one timestamp, however. You can probably find that discussion somewhere in our issue tracker if you're curious.

Or do you mean if jj updates the committer timestamp while leaving the author timestamp unchanged? Yes, that's also the same as what Git does.

We don't have --committer-date-is-author-date. I don't think we've had a single request for it until now.

That flag seems a bit weird, though. Wouldn't you want to keep whatever the committer date already was? Why would you want to reset it to the author date? Of course, after you have passed the flag once, any subsequent uses will have the same effect as keeping the committer date, so maybe that's why it's good enough. Maybe it works the way it does for historical reasons (I happened to see that it used to be passed to `git am` back when `git rebase` was based on that).

Ah, I see what you're saying now. Thanks for explaining. I agree with you in principle.

My impression from our Discord server is that quite many JJ users actually are Git experts who have been creating clean commits for years. I'm one of those people. It's not a coincidence that JJ's CLI makes it easy to create clean commits - it's designed for that from scratch.

FWIW, Drew DeVault wrote such an article but he later took it down (in protest of the Google CLA, I think). You can probably still find it somewhere.

> Since you're a git expert, you understand the underlying mechanics of your tool and you can explain to me why a command like Git rebase is better in JJ than in git.

I'm not the person you asked but I can try to explain (I started the jj project, fwiw). Some things `jj rebase` does better than `git rebase`:

* It rebases whole trees/graphs of commits. This is the scenario described at https://stackoverflow.com/questions/17315285/rebasing-a-tree.... Bookmarks/branches are always updated accordingly. `git rebase --update-refs` can do that these days, but still only for one range of commits at a time (i.e. one leaf commit).

* It lets you rip out some commits of a stack and put them somewhere else. This is the `-r` flag. See https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase for some examples. You can also reorder commits by doing things like `jj rebase -r X::Y --insert-after Z` to insert the range of commits from X though Y after commit Z. You can parallelize parts of the graph by doing e.g. `jj rebase -r C --insert-after A --insert-before D` to take an initial linear graph A..D and make C parallel to B.

* It doesn't stop when there are conflicts. You can instead resolve the conflicts when you feel like it.

* It's able to rebase merge commits well, even if there are conflicts and/or conflict resolutions in them. `git rebase --rebase-merges` with the "ort" merge strategy and rerere enabled gets close these days.

* It's about 100x faster by not touching the working copy unnecessarily. `git replay` also does that.

I just sent https://github.com/jj-vcs/jj/pull/7733 to provide some more detail in our "Git Comparison" doc.

> The impression I get from these posts, is that it would have been doable with similar effort in Git, but they just never bothered.

I don't think it would have been doable. I hear this question/comment sometimes. I sent https://github.com/jj-vcs/jj/pull/7729 to have a place to point people to.

That's correct. It's only on our roadmap so far (https://jj-vcs.github.io/jj/latest/roadmap/#better-support-f...).

We have also talked about doing something similar for tree objects in order to better support very large directories (to reduce the amount of data we need to transfer for them) and very deep directories (to reduce the number of roundtrips to the server). I think we have only talked about that on Discord so far (https://discord.com/channels/968932220549103686/969291218347...). It would not be compatible with Git repos, so it would only really be useful to teams outside Google once there's an external jj-native forge that decides to support it (if our rough design is even realistic).

I don't know why you think jj makes you produce many little commits. Are you thinking about the automatic snapshotting of the working copy? That amends (replaces) your previous commit, so you won't end up with a long chain of commits.

It's probably easiest to understand by just trying it. It can be used with regular Git repos.

Yes, that's correct. It's also correct to say that you don't "need" the Git porcelain commands because it's perfectly doable using Git plumbing :)

Yes, the result is (almost) just regular Git commits, so there isn't anything jj can do that Git cannot do. It's just often a lot easier to do it with jj.

A lot of jj users are former Git power users. If all you do you use is `git clone`, `git commit -A`, `git push`, `git pull`, then there's much less to gain for you from switching.

Since you seem to know how to use interactive rebase, I think you are the target audience.

To clarify what's easier in the scenario mentioned above:

1. You don't need to check out a specific branch to start the interactive rebase from. You simply check out the commit you want to edit and then squash into.

2. You don't have to manually rebase other descendant branches. (I.e. if the commit you're modifying is in multiple branches.)

3. Branches (jj calls them bookmarks) get automatically updated. I know Git now has `--update-refs`, but you never need pass that with jj (maybe Git has a config for it, I haven't checked).

4. If you had a dirty working copy before you decided to fix up this commit, you won't need to manually stash or commit those changes.

5. If editing the commit results in conflicts in some descendant, you don't have to resolve those right away.

Try it and let us know how it goes?

In some sense, every jj command does more than any single git command because they implicitly amend the working-copy commit and rebase any descendants on top.

Another example is `jj rebase -d main`. It may look very similar to `git rebase main`, but it rebases a whole tree. See https://stackoverflow.com/questions/17315285/rebasing-a-tree... if you don't know what I mean.

Another example is `jj squash --from main..my-branch --into my-other-branch some/path`, which removes all the changes to `some/path` that happen in any commits in `main..my-branch` and squashes them into the tip commit of `my-other-branch`.

Does that help? I'm not sure I understood your comment correctly.

I'm not sure if you meant "how" or "why". As for "how", it's done by rebasing 'u' onto 's' and then rebasing 't' and 'v' onto the rebased 'u'.

As for "why", I think it behaves different from what you expected in two ways. The first is that `--revision` rebased only the specified revisions without theirs descendants (there's also `--source` if you want to include the descendants). The other things it that `--after` is a short form of `--insert-after`, so it's designed for inserting commits between other commits. There's also `--before/--insert-before`. There's also `--destination` which is what you expected (perhaps `--onto` would have been a better name for it). You can pass multiple commits to all these arguments, btw (yes, that includes `--destination`, so you can create new merge commits with `jj rebase`). https://jj-vcs.github.io/jj/latest/cli-reference/#jj-rebase has many examples.

Yes, it was to avoid ambiguity between the two kinds of IDs. See https://github.com/jj-vcs/jj/pull/1238 (see the individual commits).

We have database-backed storage backends for Jujutsu at Google. There's no Git involved there. So I think it's wrong to say that it's a wrapper for Git.

Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.

I'm not sunshowers, but I think the point isn't the exact number or a way of measuring it. For example, the reason I prefer to write Rust over C++ is not that I have measured it to be 2.6X faster for me to work with. My interpretation of what sunshowers was saying was more like "'technically better' can be enough, depending on much better it is, and I think Jujutsu is a big enough improvement [for me] that it's worth it".

We were actually talking about this for quite a while on Discord yesterday. The duality is visible to the user in jj as least as much as it is in git.

Some command arguments treat commits as snapshots (e.g. `jj restore --from/--into`, `jj diff --from/--to`, `jj file list -r`) and some commands arguments instead inspect the diffs (e.g. `jj rebase -r/-b/-s`, `jj diff -r`, `jj squash --from`, `jj log <path>`).

The first-class conflicts (https://jj-vcs.github.io/jj/latest/conflicts/) allow jj to be much better at treating commits as diffs than git is. In particular, there's no real difference between merge commits and other commits; any commit can introduce conflicts and any commit can resolve conflicts. We define the changes in a commit as relative to the auto-merged parents. That means that the diff-centric command arguments work in a consistent way for merges too. For example, if you create a new merge commit (`jj new A B ...`), it might have conflicts, but we still consider it empty/unchanged. If you resolve the conflicts, then `jj diff` will show you the conflict resolutions, and `jj rebase` will rebase the conflict resolutions (a bit like git rerere, but it also works on hunks outside of the conflict areas).

It's hard to find that information because neither git nor jj report usage information to a central place. The best I've been able to find is number of Homebrew installs, which says ~1.2k 30-day install for jj and ~162k for git, so it's about 0.7% based on that number. Who knows how many of those installs (of either tool) are actually used as the person's daily driver.

I apologize if my sibling comment sounded harsh. I think you were saying that jj could be implemented as some Git aliases. Given the information available in this thread, that might seem reasonable. I didn't realize that this thread did not include a link to the project's docs. Sorry about that.

I think you misunderstood. Did you see the list of features? My example is not the only thing jj does.

Have you tried asking your colleagues? What did they say?

To move the changes in file `foo` in the working copy into a past commit `X`:

`git commit --fixup=X foo; git stash; git rebase -i X^; git stash pop`

`jj squash --into X foo`