Hacker News Reader

Comment by Zambyte | Hacker News Reader

After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.

View on HN

100% agree.

The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.

There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.

But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.

But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to?

I don't know where I called anyone lazy.

I'll have to dig into https://github.com/martinvonz/jj hadn't heard of it before. Either way, there's an underlying data structure with operations to be performed on, the interface to it is shit, and learning the underlying data structure makes it all make sense.

So where is the totally refactored/revamped CLI that applies Occam's Razor ?

Jujutsu

https://github.com/martinvonz/jj

I see that (in principle at least) it can be a simple UI for an existing git repo but then it gets kind of complicated again discussing how that works.

I can tell you how to do a bunch of things with Jujutsu without looking it up: how to rebase a tree of branches given a common ancestor, how to do a 3+ way merge, how to split the changes in a commit into multiple commits, how to duplicate a branch, how to find all of the commits that haven't made it into the default branch...

I can't tell you how to do a single one of these things in git without looking it up. My years of experience with git is around a decade I think. My experience with Jujutsu adds up to about 3 months.

Sure, there are things that I would still have to look up how to do with Jujutsu; I don't know all of its features. I think the operations I know how to do with Jujutsu off the top of my head are strictly a superset of the operations I know how to do with git though.

There's a common(?) use case for git/jujutsu that I can't find a simple answer to:

I clone a repo. I make some changes to my copy. But then I want to keep my copy up to date with the original repo by stirring in all the updates that have been made lately to the original repo.

Seems like it oughta be simple, but git makes it mysterious. Will jujutsu make this possible using only simple, sensible CLI commands ? And conflicts will be nicely stored away for near-term cleanup ?

Inquiring minds want to know.

jj fetch # get the most recent changes from the remote

jj rebase -b @ -d branch@remote # rebase the branch of the current working commit onto the newly fetched commits.

Note that the way to do this with git is almost identical, but maybe not as obvious. In git I think this can be done with a single command though: git pull --rebase.

If this is not the state you want your repo to be in and I misunderstood, I'm still pretty confident I could get a repo in the state you want using Jujutsu quite easily :)

Edit: though also the git way to do this would kind of force you to deal with cleaning up conflicts immediately, whereas with Jujutsu you can put off conflicts indefinitely.

Reply on news.ycombinator.com