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

21–30 of 233 posts

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

#21

Post by martinvonz »

freedomben wrote: post #10

This looks like an interesting project, and I'm glad that people are still thinking about how to improve on version control. That said, building a version control system seems like a problem similar to a social network: the network affect causes an enormous amount of friction. i.e. most people don't want to use it until other people are using it. A vicious cycle. The fact that it's compatible with git as a backend is…

> For example, "when the working copy is automatically committed," where does it go?

It becomes a regular git commit with a git ref called something like `refs/jj/keep/9f1a0fb0-a0aa-4a4b-922f-d6d48687996a` pointing to it (to prevent GC). It won't get fetched or pushed by default, except with `--mirror`, I think.

> If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so I can easily run `./mycode video.mp4`

Yes! You'll have to more diligent about keeping your .gitignore (or .git/info/exclude, etc) file updated. I plan to add commands for fixing such mistakes by forgetting the commit.

> Do you have to use the jj backend to get all the feature?

Nope, conflicts work with the git backend as well. https://github.com/martinvonz/jj/blob/main/docs/git-compatib... has some info.

> To sum up my comment in a TL;DR: To really sell me on a project like this it has to work with git, and being able to quickly tell which features I can use with git, would make this substantially more interesting to me.

Makes sense. Thanks for the suggestion! I'll put it on my TODO list.

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

#22

Post by throw0101a »

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". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them.

Mercurial has an 'index' / staging area, but not exposed by default. You can access it with some extra CLI options, but there is an optional idea that may be 'better' and worth looking into:

> If you need the index, you can gain its behavior (with many additional options) with mercurial queues [1] (MQ).[2] Simple addition of changes to the index can be imitated by just building up a commit with hg commit --amend (optionally with --secret, see phases [3]).

* https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi...

[1] is "A Git User's Guide to Mercurial Queues"

* https://stevelosh.com/blog/2010/08/a-git-users-guide-to-merc...

MQs (optionally) expand on the idea of only a single staging area:

> This single "intermediate" area is where git stops. For many workflows it's enough, but if you want more power MQ has you covered.

> MQ is called Mercurial Queues for a reason. You can have more than one patch in your queue, which means you can have multiple "intermediate" areas if you need them.

If you only want to use one queue/index then that's fine too.

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

#24

Post by Hendrikto »

freedomben wrote: post #13
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 provi…

What you are describing sounds as if you want worktrees: https://git-scm.com/docs/git-worktree

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

#25

Post by [deleted] »

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…

[deleted]

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

#26

Post by indygreg2 »

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…

The index is a power user feature. Its forced presence in Git effectively constitutes a usability barrier for new users. After all, a VCS is effectively a glorified abstraction for "save a file." Any barrier imposed between changing a file and committing it can get in the way and confuse people. The Git index does this.

Furthermore, the index is effectively a pseudo commit without a commit message. Any workflow using the index can be implemented in terms of actual commits itself.

I think because Git doesn't have strong usability in general and especially around history rewriting, many Git users feel that the index or an index equivalent is somehow a required feature of a VCS because Git's shortcomings give that illusion. However, if you use a VCS with better history rewriting (such as Mercurial with evolve), you'll likely come around to my opinion that the index can be jettisoned without meaningful loss of functionality or productivity.

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

#27

Post by skrebbel »

Wow, this scratches a lot of my itches about Git. I teach a Git course at my alma mater, and the things that confuses people the most (the index, how to undo mistakes etc etc) all seem addressed head-on. At first glance, this seems substantially easier to teach than Git.

The Git compat seems like a great idea for this to really take off. My team is totally PR based though so if/when doing (Git compatible) feature branches lands in JJ I'm excited to switch.

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

#28

Post by omegalulw »

martinvonz wrote: post #12
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…

> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits.

This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in?

Not to mention that another benefit of an index is being able to change commits and git replaying your working diff.

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

#29

Post by hinkley »

“Powerful” has become to me a shibboleth for people who are full of it.

I can’t recall the last time a coworker who liked things because they were powerful didn’t end up being untrustworthy. Even dangerous. It’s like nobody remembers the Principle of Least Power.

That said, I will take someone obsessed with “powerful” over “flexible” any day of the week.

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

#30

Post by KerrAvon »

martinvonz wrote: post #16
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.

I haven’t watched that video, but I agree — the index is one of the biggest hurdles to making git easy to understand and use for newcomers. It’s not hard to explain the fundamental model of how git works — it’s hard to explain the UI, and it’s hard to explain the index. If you remove the index, you’re only working with commits, and that simplifies the UI enormously.
Post reply on HN