Comment by tripple6 | Hacker News Reader

Comment by tripple6 | Hacker News Reader

Parent Full thread

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed.

> You can UNDO. Everything. That is the major thing

Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean.

> You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice.

It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

> The command made sense

It's nice.

> Nobody else knows you use `jj`, so no barrier to adoption.

It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS?

> Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT!

I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git.

> but does it work as a front-end tool over git/other VCS?

citing from the article

> Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend.

> I don't get it. What does make rebase hard?

It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1].

Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2].

[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

[1]: https://graphite.dev/

[2]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

Regarding the rebase thing, I guess it's more a matter of habit. Stacked branches indeed may be tedious and may be annoying to rebase, agree. I implemented a shell script to rebase branch trees on top of a new base that would cover stacked branches as well. It covered all my needs like resolving conflicts, concluding or aborting the branch tree rebase and so on. Of course, it would be nice to have such a right-done thing right in git. But as of now, if I understand what jj is, it seems like I can shell-script some of its features myself. Still a happy git user.

I think the best way to answer most of your questions is just for you to try it yourself (https://jj-vcs.github.io/jj/latest/install-and-setup/).

> Everything is what?

Not interactions affecting remotes (you can't unpush a commit). Configuration is also not tracked. Neither are ignored files.

You can undo changes in the working copy, rebases, splits, squashes, etc.

> The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset.

Files added to the index can be recovered at least, but it's not easy to find them. The bigger problem is if you have not added them to the index and run e.g. `git reset --hard`. You can't undo that (via Git, but maybe via your IDE or your file system).

It's also about ease of use. I know you can undo a lot of things by using Git's reflogs, but it's not easy to e.g. undo a `git rebase --update-refs` that update many branches.

> I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

Yes, Jujutsu also supports that (`jj workspace`), but IMO, it's nice to not have to use them just because your working copy is dirty.

> What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode.

I've worked on the `git rebase` itself, so it's not like I don't know how to use it. Some things that I think are wrong with it:

* Without `--update-refs`, it only rebases a single branch. That's basically never what I want when I have branches pointing to other rebased commits.

* It's not able to rebase more than one head (no trees of commits)

* Doesn't rebase merge commits properly. Instead, it redoes the merge, discarding any conflict resolutions. (Yes, I know about rerere.)

> Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

Mostly that it's so stateful. While doing an interactive rebase (e.g. editing a commit), you're in a state where you can't easily check out another commit, for example. If you run into conflicts, you have to finish resolving all conflicts in the stack of commits, or you have to abort the whole rebase (throwing away any previous conflict resolutions).

Again, it will be easier to understand if you just try using Jujutsu for a few days.

Reply on news.ycombinator.com