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

Jujutsu at Google [video]

youtube.com

Post reply on HN
Print view View original

71–80 of 212 posts

Re: Jujutsu at Google [video]

#71

Post by fernandotakai »

bqmjjx0kac wrote: post #42
nh23423fefe wrote: post #23

Earlier quoted context omitted.

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.

and i honestly would rather parse json inside ipython and then move to a script, than keep invoking `| jq` time and time again.

Re: Jujutsu at Google [video]

#72

Post by qudat »

dakiol wrote: 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…

When you start doing git surgery where there are commit chains that need to stay logical is where JJ starts to shine. If you are constantly editing previous commits and placing code in your working area into those previous commits and rebasing original/main.

I also really like that every change is automatically committed. It’s a great mental model once you get used to it.

Re: Jujutsu at Google [video]

#73

Post by shadowgovt »

skirmish wrote: post #70
shadowgovt wrote: post #34

Earlier quoted context omitted.

MacOSX is a popular choice for dev boxes (if I understand correctly, they provide some pretty good tooling for managing a fleet of machines; more expensive hardware than a Linux dev machine fleet, but less DIY for company-wide administration). ... but Google solves the "A Linux fleet requires investment to maintain" problem by investing. They maintain their own in-house distro.

> their own in-house distro Not really, it is just a well known outside distro plus internal CI servers to make sure that newly updated packages don't break things. Also some internal tools, of course.

Relative to what the rest of the world does, that is maintaining your own in-house distro.

It's downstream of Ubuntu (unless that's changed) but it's tweaked in the ways you've noted (trying to remember if they also maintain their own package mirrors or if they trust apt to fetch from public repositories; that's a detail I no longer recall).

Re: Jujutsu at Google [video]

#74

Post by thefifthsetpin »

nh23423fefe wrote: post #23
dakiol wrote: 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 long been facinated by how bimodal understanding of git is. I'm one of the lucky ones to whom it came naturally, but there's clearly a large population who finds git challenging even after investing significant time and effort into learning it.

I don't see this anywhere nearly as drastically with other tools.

Re: Jujutsu at Google [video]

#75

Post by metabagel »

nh23423fefe wrote: post #23
dakiol wrote: 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

From time to time, I end up in a state which I don't know how to recover from, and it's very frustrating to have to take an hour or two from my real work in order to try to figure out how to get out of that state.

https://roadrunnertwice.dreamwidth.org/596185.html

Re: Jujutsu at Google [video]

#76

Post by kubanczyk »

dakiol wrote: 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…

> So, what am I missing?

Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.

Re: Jujutsu at Google [video]

#77

Post by metabagel »

OkayPhysicist wrote: post #56
cosmosgenius wrote: post #41

Earlier quoted context omitted.

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).

My go-to solution for this problem is a git init --bare --shared=group repository in a shared mountable drive. Then you can declare that repo origin, and tada, git push/pull works.

> git init --bare --shared=group

This is a very git command.

Re: Jujutsu at Google [video]

#78

Post by Cyph0n »

OkayPhysicist wrote: post #60
Cyph0n wrote: post #26

Earlier quoted context omitted.

Good advice for presenting a TEDx talk. Bad advice for a technical talk.

If you don't care about the material, why on earth would anybody sit around for 15 minutes/30 minutes/an hour listening to you talk about the material. The sole reason for a presentation over a technical reference buried somewhere is because the presenter wants the audience to care about the thing they're presenting. If that isn't reflected in the presentation, it's not a worthwhile presentation.

But this was a technical presentation at a conference dedicated to the technology in question. A person stumbling across this on HN does not magically make them part of the target audience.
Post reply on HN