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

Jujutsu – A Git-compatible DVCS that is both simple and powerful

github.com

Post reply on HN
Print view View original

11–20 of 233 posts

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#11

Post by bonzini »

yjftsjthsd-h wrote: post #7
cryptonector wrote: post #5

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#12

Post by martinvonz »

cryptonector wrote: post #5

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

> You lost me at "free from the index".

If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparis...), there's an explanation there for how to achieve the same workflows. I get that it's different, but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched to Mercurial ~7 years ago.

> This is very welcome.

Thanks :)

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#13

Post by freedomben »

jareds wrote: post #3

This looks interesting and I'm glad to see that people are not viewing SCM as a solved issue. While I don't think I'd use this on professional projects yet I'm interested at looking at this for personal projects since I can use the Git back-end and continue to use Github to host my code. I feel like Git has become such a DeFacto standard that nothing is going to replace it any time soon. I've been programming for lon…

I remember that well too (along with Rational Clearcase), and you may totally be right, but git does feel different because it works so well with all sorts of projects, big and small. There were always operations that required hacks. With git that doesn't feel the case to me,perhaps with one exception (but I don't think this is git's fault as much as it's mine for not knowing git well enough to use the tools it provides): if I'm working simultaneously on two different branches (for example one branch is a bug fix that requires 20 minutes to build and deploy before I can test it, so I work on other things while it's running), I often have two different checkouts so I can (mostly) avoid having to git stash.

That said though, you are probably right something will eventually supplant git. It would be arrogant to think that my failure to imagine something better means there isn't anything.

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#14

Post by dilap »

cryptonector wrote: post #5

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

I like and use the index in git too, but I wouldn't be so quick to dismiss other models that might end up solving the same use cases in a different way...

From the README, it looks like there's robust support for editing and splitting commits. So maybe in practice the flow is similar to using the index, with the added the added benefit that your work is backed via commits along the way, and the simplicity of not having the index as an extra concept.

In general when exvaluating X from the perspective of Y, we will immediately see the thing's about Y we like that X lacks; it takes more time to see if perhaps in the fuller context of X those things are not necessary.

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#16

Post by martinvonz »

swagonomixxx wrote: post #6

> A Git-compatible DVCS that is both simple and powerful We all know the dig here - Git is not simple. Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago. Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly b…

> I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.

Perhaps the biggest mistake (IMO) was to expose the index to the user. I happened to just watch https://www.youtube.com/watch?v=31XZYMjg93o (by the person behind Gitless). They explain the issues well there.

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#17

Post by masklinn »

cryptonector wrote: post #5

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index i…

> Right, so, the reason the index is powerful is that I get to do `git add -e`, `git commit`, and repeat until I'm done or ready to throw remaining changes away.

You don’t need the index for that. In fact I’d say it gets in the way because the presence of the one means less pressure on improving the ability to edit commits: while it’s easy to add stuff to HEAD it’s much more painful to remove content from it.

If that is solved, then the value of the index drops precipitously, because you can create a commit with a purpose and select its content instead of having to do it the other way around then forgetting what change you were trying to craft.

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#18

Post by masklinn »

bonzini wrote: post #11
yjftsjthsd-h wrote: post #7

Earlier quoted context omitted.

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

> You do that with a sequence of "git add -p" and "git commit" commands.

You can do that with git commit -p.

Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful

#19

Post by martinvonz »

bonzini wrote: post #11
yjftsjthsd-h wrote: post #7

Earlier quoted context omitted.

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

> I am interested in how to do this with jj

`jj split -r `, where `` may be the working copy commit (which is the default). See https://github.com/martinvonz/jj/blob/main/docs/git-comparis... for more examples.

Post reply on HN