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

Jujutsu Megamerges and jj Absorb

v5.chriskrycho.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Jujutsu Megamerges and jj Absorb

#31

Post by steveklabnik »

stavros wrote: post #19
stouset wrote: post #16

Earlier quoted context omitted.

There’s a configurable cap on max file size to auto-add, IIRC. It defaults to something “reasonable”. If you do somehow add a terabyte of small files by accident, it’s still just git under the hood so you can make sure nothing active points at them and GC them.

I'm thinking of something like node_modules, sounds like I'll need to not forget.

Those are usually in your gitignore, right?

Also, this behavior (automatically tracking) is configurable. I thought I would hate it but I actually really like it.

Re: Jujutsu Megamerges and jj Absorb

#32

Post by stavros »

steveklabnik wrote: post #31
stavros wrote: post #19

Earlier quoted context omitted.

I'm thinking of something like node_modules, sounds like I'll need to not forget.

Those are usually in your gitignore, right? Also, this behavior (automatically tracking) is configurable. I thought I would hate it but I actually really like it.

Yeah they usually are, I'm sure it's great because I add files more often than I ignore, but I need to be careful with the temporary files I write left and right in the repo dir during development.

Re: Jujutsu Megamerges and jj Absorb

#33

Post by steveklabnik »

evgpbfhnr wrote: post #27
stouset wrote: post #13

Earlier quoted context omitted.

Just try it! I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is. Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugg…

> Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months. That interests me -- is there a native jj protocol for push/fetch? Even if just ssh? Or do you just work in local repos?

Backends can do whatever. The git backend knows how to push to git remotes. If you used a different backend, it would know what those backends expect. There aren’t any of these publicly, but Google has one to work with piper.

Re: Jujutsu Megamerges and jj Absorb

#34

Post by fragmede »

steveklabnik wrote: post #33
evgpbfhnr wrote: post #27

Earlier quoted context omitted.

> Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months. That interests me -- is there a native jj protocol for push/fetch? Even if just ssh? Or do you just work in local repos?

Backends can do whatever. The git backend knows how to push to git remotes. If you used a different backend, it would know what those backends expect. There aren’t any of these publicly, but Google has one to work with piper.

Google's internal git support for the Google3 monorepo was deprecated/is unsupported in favor of fig, the mercurial/hg based client for Google3.

Microsoft has a custom git client internally which includes a filesystem shim (think: the Windows equivalent of FUSE) since stat-ing monorepo amounts of files doesn't work. Also GitHub's running custom git servers, though their custom database backend is behind a compatibility layer.

Finally, sapling, Meta's git replacement which maintains supports for git servers also supports sapling servers (which was not released). Unsure whether to count that as a git backend though.

Re: Jujutsu Megamerges and jj Absorb

#35

Post by ziml77 »

bayindirh wrote: post #25
Certhas wrote: post #24

Earlier quoted context omitted.

I agree that the change isn't of comparable magnitude. But JJ changes the user facing conceptual structure of version control. It unifies working directory, stash, index and commit, and replaces them with a single thing. And it shows that all existing git workflows can efficiently be constructed on this much simpler conceptual basis. In my mind this demonstrates convincingly that gits conceptual model carries unneces…

From what I understand, all these different places/things (working directory, stash, index and commit) confuses, and comes across unnecessary to some people. They want a simpler solution, and less mental load during version control phase of their software, that's understandable. In my experience software developers come in two flavors. a) Developers who want to understand all the pieces they work with and have the de…

Being in group #1 does not mean that I want to interact with every system at the lowest possible levels. I want to interact in ways that fit how I work, not to fit how I work to the ways the system works.

> "git is dead, new king is jj. Now move to your new kingdom and worship jj"

No one is saying this. If you feel like people getting excited about Jujutsu is them telling you that you must love it, that's on you. The fact that it is built on top of Git means that even if others are using Jujutsu, you are not forced to when working in the same repos.

Re: Jujutsu Megamerges and jj Absorb

#36

Post by steveklabnik »

fragmede wrote: post #34
steveklabnik wrote: post #33

Earlier quoted context omitted.

Backends can do whatever. The git backend knows how to push to git remotes. If you used a different backend, it would know what those backends expect. There aren’t any of these publicly, but Google has one to work with piper.

Google's internal git support for the Google3 monorepo was deprecated/is unsupported in favor of fig, the mercurial/hg based client for Google3. Microsoft has a custom git client internally which includes a filesystem shim (think: the Windows equivalent of FUSE) since stat-ing monorepo amounts of files doesn't work. Also GitHub's running custom git servers, though their custom database backend is behind a compatibili…

For sure. This kind of thing is very useful. It’s why jj is backend agnostic by design.

Re: Jujutsu Megamerges and jj Absorb

#39

Post by IshKebab »

Does jj do anything about submodules being horribly buggy in Git, or LFS being taped on the side as an afterthought? I guess they can fix the submodule bugs but presumably they can't fix LFS without breaking Git compatibility?

Re: Jujutsu Megamerges and jj Absorb

#40

Post by steveklabnik »

IshKebab wrote: post #39

Does jj do anything about submodules being horribly buggy in Git, or LFS being taped on the side as an afterthought? I guess they can fix the submodule bugs but presumably they can't fix LFS without breaking Git compatibility?

Right now Jj basically ignores submodules, they do want to fix it but haven’t yet. So you just use git commands in a colocated repo for now.

Large file stuff is also a “want to do something better but no progress yet” kind of thing.

Post reply on HN