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

251–260 of 269 posts

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

#251

Post by Groxx »

snthpy wrote: post #239
Groxx wrote: post #116

> safe replication via rsync, Dropbox, or distributed file system Neat. I've been leaning more and more towards systems that are dumb-sync-friendly because I can throw them anywhere with anything and they just work . Always glad to see new things doing this!

Can someone say more about this? I've heard of this issue before but haven't experienced it myself. How does it arise, I.e. what's the race condition between git and rsync/Dropbox/... that causes problems?

Git mutates files to do many of its normal operations. Dumb-syncing without being perfectly up to date before you disconnect and switch to another machine and start making more changes means you risk conflicts (new conflict-named files in Dropbox, silently clobbered changes in many, etc), and git has essentially no way to notice this and warn you about what happened or recover what you lost. So you do your stuff, later discover the sync error when you reconnect, and now you have to choose losing data or understanding git's plumbing and raw data well enough to save both by hand.

---

For example, branches. From what I can tell (I'm moderately confident here, but definitely not 100%):

Git stores branches as a file at .git/refs/heads/branch-name which contains the current commit SHA. When you make a new commit in that branch, it modifies the file's contents to contain the new SHA. Syncing a conflicting change here means... well lots of possibilities. Maybe one write silently wins and the other SHA gets silently garbage collected eventually, maybe there's now a new branch with a conflicty name, maybe you have a broken file because it contains a `diff` conflict and it has >> markers, maybe demons erupt from your nostrils.

Jujutsu stores branches as a folder at some/path/branch-name/. The current head of the branch is a file in that folder with the SHA as its filename (the file is empty), giving you some/path/branch/c0ffee . If you sync changes from somewhere else due to concurrent changes to your clone, it either agrees and there's no harm, or it becomes a new file in that folder, some/path/branch/00f .

Your local tool doesn't know which is correct, but it can tell that a conflict occurred, and both actions' results are still available.

---

That's a thing you have to design carefully around, so it's completely understandable that it's not the default. But one of the benefits is that it means you don't need special protocols to exchange data, so tons of things simply work correctly without further effort. Git has to use lock files to protect its internals, and they have numerous issues and are completely useless in some situations (e.g. NFS, Dropbox). Jujutsu simply doesn't need them, and works safely regardless of your system or usage patterns (for this at least, dunno about everything).

All this^ is why I pay to store my git repos in a git host rather than simply using my own backup systems (and why I don't have two remote backups). And it's why I avoid SQLite for much of my heavy-use personal backed-up stuff - it makes one large file that mutates, so fully syncing is a MUST before making any changes. Same with keepass - one large mutating database (but it has pretty good database merging built in, so the dozen or so conflict files I've gained are easy to resolve). There are pros and cons to splitting things up into a million files of course, but I run into sync issues pretty regularly so that's the pain I feel most keenly.

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

#252

Post by arxanas »

h0l0cube wrote: post #241
arxanas wrote: post #142

Earlier quoted context omitted.

It's not really different than using Git to work on the same branch. If you and the teammate commit to the same branch, then you'll need to resolve the divergence somehow, usually a merge or rebase, or choose to forcibly overwrite the other's changes.

I can theorize about how it might work in a team also, but I was curious how this has played out in practice for anyone

To be clear, I am describing my actual usage of jj. It’s worth noting that there’s currently not a `jj pull` command, so divergences typically involve manually setting a branch pointer for me.

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

#253

Post by RHSeeger »

arp242 wrote: post #206
RHSeeger wrote: post #178

Earlier quoted context omitted.

I've used that file before but... it always felt sort of hacky. And every time I want to use it, I need to figure out where it is. It really feels like there should be a more obvious, straight forward way to do it. Admittedly, "user friendly" is not git's strong suit.

The .git directory seems like the obvious location for it; I agree that info/exclude isn't the most obvious path (I had to look up what the exact path was again for my previous comment), but all things considered that seems like a minor issue. I suppose you could symlink .git/ignore to .git/info/exclude or something in the git template.

> The .git directory seems like the obvious location for it

The same location as .gitignore seems like the obvious location for it, to me.

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

#254

Post by arxanas »

rcme wrote: post #245
arxanas wrote: post #235

Earlier quoted context omitted.

What does the version control system have to do with build times and multi-tasking? I use jj in repositories with long builds, but I don't see what it has to do with that.

Every jj command creates a commit. So if you have two unrelated pieces of work you need to split all the commits created.

I see that the README is unclear or even misleading on this point. How it works is that, upon each command, the commit corresponding to the working copy is updated in a similar way as `git commit --amend`. You will typically only have one "working copy commit", which corresponds to "unstaged changes" in Git. The difference is that instead of using special-purpose commands like `git add` to interact with the staging area, you instead use the same set of commands that you would use to manipulate other commits. (There is a `jj commit` convenience command to model the common case of adding a commit message to the working copy commit and then creating a new working copy commit on top of it.)

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

#255

Post by jayd16 »

postmodest wrote: post #161
jayd16 wrote: post #156

Earlier quoted context omitted.

Git should really steal the only thing I like about perforce, many uncommited change lists. It should be an easy workflow change to add 'named stages' along side the default stage. That way you can just leave changes in a different stage, tracked but uncommitted.

Is that different to git stash?

Yeah, they stay in the working set but files are marked for different commits. Ideally git could do it at the line level instead of by file.

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

#256

Post by eviks »

BaseballPhysics wrote: post #250
eviks wrote: post #240

Earlier quoted context omitted.

Instead of this irrelevant pizza example you could've tried to address the real issues with your arguments (hint: the one where you liked/prefered wasn't on the list)

I see I was too subtle, so I'll be direct: you seem to be confused because I'm not having an argument . The question you might consider asking yourself is: why do you insist on trying to create an argument where none exists? This is an incredibly bad habit. Arguing with people about their personal, subjective preferences when it's clear that person isn't inviting in an argument in the first place is incredibly annoyi…

You're repeating your mistake: I didn't argue about your subjective experience, but about your more objective justification of a particular workflow.

And you've turned a constructive conversation into off-topic pizza moralizing. Don't do it

(and of course you're having an argument, just a using poor arguments)

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

#257

Post by kuchenbecker »

Double_a_92 wrote: post #242
kuchenbecker wrote: post #231

Earlier quoted context omitted.

Working on large complex projects the main branch will have dozens or hundreds of commits per day pushed continuously. The value is a consistent and linear commit history moving from known-state to known state. Facebook version control system built on mercurial is the best I've used. One of the huge benefits of the rebase based workflow is commits can be reordered and land as they pass tests rather than a single line…

You all work on one shared main branch, without any feature branches? Isn't it horrible to have other people half-finished code in the code that you are trying to work with?

Work in whatever branch you want, but if you want to merge to main and deploy it better be a stack of PRs that merge cleanly and don't expect others to wait or serialize on your change.

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

#258

Post by olodus »

josephg wrote: post #164
ChadNauseam wrote: post #100

Earlier quoted context omitted.

You should check out Pijul, as it essentially implements everything you mentioned here. Pijul works on patches which are CRDTs, it makes conflicts a first-class concept, etc.

Pijul is interesting, but my understanding is that it still operates on lines, and does diffs when you push the commit button. And that makes it not work well for real-time collaborative editing. Ideally I’d like a tool that can span both the real-time collaborative editing and offline collaboration use cases. But it’s a very interesting tool, and I’d like to have another read through the docs at some point. I rememb…

Last time I looked at it they had experimental support for binary diffs (not just lines). That was quite a while ago though, they have probably gotten further now.

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

#259

Post by eternityforest »

chaxor wrote: post #129
ocharles wrote: post #22

Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two,…

Are you simply using it with GitHub repos? It mentions that it can be used with backends like Dropbox, but it would be wonderful if we finally had a system that could easily be used with IPFS. This is especially important for large data, since you can't store 1TB on github (and no, I don't count lfs, since you have to pay for it). IPFS is the natural solution here, since everyone that wants to use the dataset has it…

IPFS didn't always seem to have pinning services at BitTorrent prices($3-$5 a month with 1TB bandwidth, no crypto wallet needed) and the client usew tens to hundreds of kb per second idle.

Unfortunately, the model of putting every block in the DHT instead of having roots mode be the default, and then spamming your wantlist to tons of peers seems to still be at least partly around.

Right now IPFS looks pretty good thanks to the gateways and services, so I would imagine well see more of it in the future, but I can see why it took so long.

Post reply on HN