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

81–90 of 212 posts

Re: Jujutsu at Google [video]

#81

Post by koiueo »

thefifthsetpin wrote: post #74
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'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.

There are simply people who've rtfm and people who haven't

Re: Jujutsu at Google [video]

#82

Post by OkayPhysicist »

Cyph0n wrote: post #78
OkayPhysicist wrote: post #60

Earlier quoted context omitted.

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.

A technical presentation is a still a presentation, as opposed to a reference document. If you want to give someone a block of technical information, you do so in a reference document. You talk in front of a room full of people in order to convince them that this matters enough to bother.

Re: Jujutsu at Google [video]

#83

Post by elAhmo »

qudat wrote: post #72
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.

Git rebase works fairly well and is somewhat uneventful, unless there are major changes happening. I do hate the experience when one file was remove in my feature branch, but main did a major refactor which affected the original file, so conflicts are a bit awkward then - but other than that, this seems like a fairly clean workflow.

Re: Jujutsu at Google [video]

#84

Post by Cyph0n »

OkayPhysicist wrote: post #82
Cyph0n wrote: post #78

Earlier quoted context omitted.

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.

A technical presentation is a still a presentation, as opposed to a reference document. If you want to give someone a block of technical information, you do so in a reference document. You talk in front of a room full of people in order to convince them that this matters enough to bother.

Sure, but I don’t think this is relevant to the comment thread we’re in, which started off by sharing generic advice that mostly applies to TED-style motivational talks or “keynotes” at large conferences etc.

Re: Jujutsu at Google [video]

#85

Post by gorjusborg »

metabagel wrote: post #75
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

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

The reflog is the failsafe. It is the tool that fixes all the scary states, as it keeps a journal of the states of each ref in the repo (like branch heads).

You can see where you were and hard reset back, no matter what state you are in.

Re: Jujutsu at Google [video]

#86

Post by litenboll »

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 think what people usually mean is "scary" or "it's easy to mess up". Git is very easy to use until you mess up, then it can become complicated, and certain actions may have devastating consequences.

Two examples from recent memory:

Someone merged the develop branch into their branch, then changed their mind and reverted the merge commit specifically (i.e. reversing all the incoming changes), then somehow merged all of this into the develop branch, undoing weeks of work without noticing. I had to go in and revert the revert to undo the mistake. Yes they messed up, but these things happen with enough people and time.

Another very interesting issue that happened to a less technical person on the team was that their git UI somehow opened the terminal in the wrong folder. They then tried to run some command which made git suggest to run 'git init', creating another git repo in that wrong location. Fast forward some days and we had an issue where people had to clean their repos, so I was in a call with the person helping them run the clean command. The UI opened the wrong location again, I helped them put in the command and it started cleaning. The problem was that this git repo was essentially at the top level on their disk, and since was a fresh repo every single file was considered a new file so it tried to delete EVERYTHING on their disk. This was of course mostly my fault for not running git status before the clean command, but this potential scenario was definitely not on my mind.

Re: Jujutsu at Google [video]

#87

Post by aidenn0 »

verdverm wrote: post #64
thibran wrote: post #46

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

No LFS, submodules, hooks, or new tags means jj has some ways to go before it is a viable replacement for many organizations https://jj-vcs.github.io/jj/latest/git-compatibility/

Having used git submodules, I see a lack of them as a feature. I honestly think that a script that checks out a specific commit from an external repository, combined with adding the path to the .gitignore is strictly better than submodules.

Re: Jujutsu at Google [video]

#88

Post by LtWorf »

thefifthsetpin wrote: post #74
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'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.

> after investing significant time and effort into learning it.

And the significant time and effort amounts to a total of 15 seconds.

Re: Jujutsu at Google [video]

#89

Post by Agingcoder »

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

So based on my experience teaching git ( I remember a cvs to git migration …) , reality tells me people find git difficult.

Now, once you teach them it’s a commit graph with names, some of them floating, some people get it.

The thing is, not everyone is comfortable with a commit graph, and most people are not - just like people get lists and arrays but graphs are different.

So I agree with you on principle ( it shouldn’t be difficult), but most people don’t have a graph as a mental model of anything, and I think that’s the biggest obstacle.

Re: Jujutsu at Google [video]

#90

Post by aidenn0 »

inamberclad wrote: post #11

Not really on topic, but I think it's funny that most MMA style gyms always offer Jiu Jitsu and Muay Thai as two classes, right after each other. Of the two, Jiu Jitsu seems to generally be the more popular one.

Muay Thai is murder on the joints. BJJ, with its focus on ground-work is much easier on my nearly 50-year-old joint.s
Post reply on HN