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

201–210 of 233 posts

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

#201

Post by ParetoOptimal »

martinvonz wrote: post #168
lostintangent wrote: post #139

This is awesome! And it’s so exciting to see folks investing energy into this problem space. Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?

Good question. You're right on both guesses. One reason is that I want to make sure the API works well enough that it's easy to replace the backend. The current native backend is called `local_store` because it stores files locally (just like the Git backend does). I want to be able to add another backend that fetches objects from a remote instead (and caches them locally), although another option is to hide that par…

> I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet.

Awesome, that would enable a realistic no-risk path to adoption for most projects:

- trying jujutsu on work codebase

- if useful, tell a coworker and maybe they try it

- present internally about pros

- team tries and agrees its better, adopts it

- after some months confidence is built, give a presentation on features you could get with jujutsu native backend, gauge interests\worth

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

#203

Post by hinkley »

chrismorgan wrote: post #193
tragictrash wrote: post #160

Earlier quoted context omitted.

It's not that hard man. Really isn't. Your anecdote sounds like someone who thinks they're awesome at git setting a noob up for failure and then mansplaining when they fuck up. It's not hard to be better at git than 85% of people, most devs I've met don't understand the basics beyond pull commit push.

It must be admitted that if merges are involved , it becomes somewhat harder to do something like this, as you can no longer use the easy and safe path of an interactive rebase to edit the commit and remove the file, and must reach for filter-branch or similar, which are generally a good deal scarier and easier to make difficult-to-identify mistakes with. (Fortunately, the man page git-filter-branch(1) deals with thi…

Almost all of the complexity of VCS is in or around merges. Take away accidental complexity and there is a lot of inherent complexity in merges.

First git project we had a guy who was bad at merges, and his solution was to avoid them as long as he could, which just made things worse. He also disliked another engineer. That engineer was definitely making mistakes but at the end of the day his Dunning Krueger was causing me less trouble than merge boy’s. Also suspect a little ageism, but would not have been able to defend that suspicion.

So one day merge boy was loudly exclaiming that old guy had written a terrible bug and the hit history proved it. Only the bug in question was something I specifically looked for in the code review, and had been happy to find that he had gotten it right. But here in git annotate it shows he got it wrong. What the hell?

So I step through the commit history one commit at a time, sure enough the code was initially correct… until merge boy did a merge and fucked up the three way. Again. And got old guy’s name to show up in annotate. I didn’t even know you could do that.

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

#204

Post by radlad »

rhabarba wrote: post #202

Finally! Another VCS!

I think the network effect that Got has is one of the biggest reasons no other VCS has succeeded at user adoption in recent years.

By allowing a Git backend to use the Jujutsu frontend it could develop a following.

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

#205

Post by jeltz »

uses wrote: post #121

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly m…

Agreed, the index is one of my favorite parts of git. I do _not_ want to add everything almost ever.

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

#206

Post by blagie »

lillecarl wrote: post #42
blagie wrote: post #38

This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is the first project I've seen which appears to understand and respect /how/ and /why/ the git data model is so elegant.

The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.

One of the many breakthroughs in git was precisely not being patch based. Being patch-based means that the tools for comparing versions are hard-coded into the data format. One of the major upsides of CVS->SVN, for example, was support for file moves. Simple issues like this weren't possible to fix without reworking the whole system.

With a version-based model, how you compare them is determined by the user space, whether that's merges, or viewing history. Even compression isn't all that fundamental to much of anything; it's possible to implement underneath the system, eliminating whatever redundancy you want. With patch-based systems, all of that comes baked into the underlying representation.

On a deeper level, this feeds into how git can be distributed, robust, yet very simple.

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

#207

Post by lillecarl »

blagie wrote: post #206
lillecarl wrote: post #42

Earlier quoted context omitted.

The pijul model makes even more sense to my brain, being patch based solves a lot of branching issues.

One of the many breakthroughs in git was precisely not being patch based. Being patch-based means that the tools for comparing versions are hard-coded into the data format. One of the major upsides of CVS->SVN, for example, was support for file moves. Simple issues like this weren't possible to fix without reworking the whole system. With a version-based model, how you compare them is determined by the user space, wh…

It also means cherry picking commits between branches prevents clean merging afterwards meaning you have to force yourself to keep branches short-lived. The patch graph pijul gives you doesn't have this issue. I'm not an expert, but when reading the Pijul blog it made a lot of sense for me.

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

#208

Post by NateEag »

CRConrad wrote: post #194
qbasic_forever wrote: post #82

That's very cool to have support for rsync/dropbox collaboration of the repo files. I'm always sad that there isn't a maintained p2p git implementation anymore. I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it.

> there isn't a maintained p2p git implementation anymore. What, it isn't actually a decentralised distributed system any more?!? > I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it. Are you saying one can't do that with the latest versions of git? WTF, when did this happen and how can I have missed what must have been huge news when it happened?

As one who has set up skunkworks git boxes before, I think OP is probably referring to the fact that there is not a no-brainer out-of-the-box way for git repos on different dev machines to autodiscover each other, even on a local network.

You can have everyone manually set up a git hosting env on their dev machine, then have everyone manually add a remote for every other developer's box, but it sure isn't convenient.

And if you settle on sharing one central box as the canonical node (which IMO is the right answer), you're no longer truly using a distributed system - it's a de facto centralized system.

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

#209

Post by cudgy »

bitcharmer wrote: post #162
CGamesPlay wrote: post #114

Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for…

Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.

Why have 500mb of dependencies if they dwarf your app and are too large to have in your source tree?

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

#210

Post by user-the-name »

iveqy wrote: post #185
user-the-name wrote: post #184

I can't find it mentioned anywhere, but does jj support submodules? And does it make them actually work, unlike the broken mess git has? This is the biggest thing keeping me using mercurial, the fact that it has subrepos that work.

What do you think is broken with git submodules?

Everything? The default state after checking out a git project with submodules is for them to be in the wrong state! Keeping the state of submodules and the main repo in sync is a complete shambles.

Try mercurial to see how to do it correctly.

Post reply on HN