Live data from Hacker News

Jujutsu at Google [video]

youtube.com

41–50 of 212 posts

Re: Jujutsu at Google [video]

#41
post #18

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…

one thing which causes problem with git for me is collaborative work without using "git server". This usually comes up at homelab situation with no access a "git server" or ssh server. One thing with jj is i can use existing sharing mechanism like dropbox, google drive or if nothing else just copying jj folder (granted all of those are bad idea w.r.t vcs but still).

Re: Jujutsu at Google [video]

#42
post #18

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok

I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.

Re: Jujutsu at Google [video]

#43
post #28
post #21

Earlier quoted context omitted.

Not to be a jerk, but 'hundreds of devs and dozens of MR per day' is not 'huge repos'. Certain functionality only becomes relevant at scale, and what is easy on a repo worth hundreds of megabytes doesn't work anymore once you have terabytes of source code to deal with.

> terabytes of source code You sure that exists? Git repositories that contain terabytes of source code? I could imagine a repo that is terabytes but has binaries committed or similar... But source code?

Google had 86TB of sourcecode data in Piper way back in 2016.

Re: Jujutsu at Google [video]

#45
I'm trying to understand, would jj's first class conflicts solve the issue of having "stacks" of PRs that can easily be updated at any point in the stack? This is one of the features most absent from git, but prevalent in Google's tooling as well as Meta's. The only good known solution I know is graphite.dev

Re: Jujutsu at Google [video]

#47
post #19
post #6

>Jujutsu, aka JJ, is an open-source, Git-compatible VCS

Thanks for that context. Why would I want to use it instead of git?

Because it's nicer tool to use. To borrow someone else's descriptions (paraphrased), it's simultaneously simpler than git and more powerful than git. Some things that were a source of friction in git (e.g. any non trivial rebase) just stop being so.

Re: Jujutsu at Google [video]

#48
post #33
post #19

Earlier quoted context omitted.

Thanks for that context. Why would I want to use it instead of git?

Because you work for Google, or because you don't want to wait for official git to be rewritten in Rust.

As I recall, git5 was such a piece of junk that they deleted it so nobody could use it any more. It had its fans but they were all deluded. It was a demonstrated fact that git5 users were less productive than normal g4 users.

Re: Jujutsu at Google [video]

#49
post #18

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok

I've worked with many folks over the years after learning myself...

The feeling of complexity comes from not yet understanding that commits are just sets of changes to files. They are then thrown off the scent by new terms like origin clone vs push and pull, merge vs rebase, HEAD increment notation vs other commit hashes.

Once people start with a local understanding of using git diff and git add -p they usually get the epiphany. Then git rebase -i and git reflog take them the rest of the way. Then add the distributed push and fetch/pull concepts.

Re: Jujutsu at Google [video]

#50
post #46

jj is so good, finally a tool to replace Git. SVN -> Git -> jj

That's an excellent description.

I still remember feeling like a badass using Git-SVN on my SVN-based team, and being the only guy who could actually correct bad merges and restore lost data without having to plead to our SVN admin.

And now I'm feeling like a badass using jj on my Git-based team :)

Post reply on HN