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

161–170 of 212 posts

Re: Jujutsu at Google [video]

#161

Post by durin42 »

martinvonz wrote: post #59
redleader55 wrote: post #40

Earlier quoted context omitted.

I think GP is suggesting using less words on a slide, having visual aids and often, thinking of 2-3 ideas that someone would remember from your presentation. To the first point, if you take more than 1 min on a single slide, you need to split it into more slides. Also, present things that you are passionate about if you want to make people care about your presentation.

Putting less details on the slides is something very actionable. Thanks. > Also, present things that you are passionate about if you want to make people care about your presentation. Haha, this topic is something I'm very passionate about. That's how I look when I'm excited :)

> That's how I look when I'm excited

I can confirm this (we've worked together)

Re: Jujutsu at Google [video]

#162

Post by rmwaite »

Agingcoder wrote: post #149
koiueo wrote: post #125

Earlier quoted context omitted.

That's really unexpected. To me, git documentation was one of the best cleanest official docs I've ever read. Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a goo…

This is exactly what I meant. https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N... The book says that ‘ To really understand the way Git does branching, we need to take a step back and examine how Git stores its data’ then it starts talking about trees and blobs. At that point you’ve lost almost everyone. If you have a strong interest in vcs implementation then fine, otherwise it’s typically the kind of de…

To be honest, if you’re using a tool that stores things as trees and blobs and almost every part of its functionality is influenced by that fact, then you just need to understand trees and blobs. This is like trying to teach someone how to interact with the file system and they are like “whoa whoa whoa, directories? Files? I don’t have time to understand this, I just want to organize my documents.” Actually I take that back, it isn’t /like/ that, it is /exactly/ that.

Re: Jujutsu at Google [video]

#163

Post by steveklabnik »

Mic92 wrote: post #150
stouset wrote: post #118

Earlier quoted context omitted.

Git rebase is an enormous pain in the ass. Rebases must be done linearly. And right now ! Oops, you made an error in an earlier stage of the rebase? Start over, good luck! Want to check something from earlier while you’re in the middle? Sorry, you’re in a modal state and you don’t get to use your regular git tooling.

git has rerere for this usecase, jj doesn't - you have to find the conflict resolution manually in your history in this case if you made a mistake.

git has rere, but jj doesn't because its equivalent is built in. https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... is some discussion about the differences here.

Re: Jujutsu at Google [video]

#164

Post by 1718627440 »

stouset wrote: post #118
elAhmo wrote: post #83

Earlier quoted context omitted.

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.

Git rebase is an enormous pain in the ass. Rebases must be done linearly. And right now ! Oops, you made an error in an earlier stage of the rebase? Start over, good luck! Want to check something from earlier while you’re in the middle? Sorry, you’re in a modal state and you don’t get to use your regular git tooling.

You can just record all your changes with git commit --fixup and then do a non-interactive rebase that just applies all the changes.

You can use all the regular git tools in a rebase, in fact it would be quite useless without. You can also just jump to other branches or record a fix to a previous commit. It doesn't matter what you do in the meantime, it only cares what is the HEAD, when you call git rebase --continue, and then it only performs what commands you specify in the rebase todo. You can even change the todo list at any time.

Re: Jujutsu at Google [video]

#165

Post by martinvonz »

ramses0 wrote: post #158
martinvonz wrote: post #10

Earlier quoted context omitted.

Thanks for the link. I went through it but I'm not sure what it's telling me to change. Can you elaborate? If it's "be more engaging", i think is unfortunately going to be hard to improve because this is just how i am.

Again, amazing to be seeking feedback (or open to it). I'm at minute 13 (code review management / bookmarks, etc.), and will give my feedback from there: https://www.essayselevate.com/post/how-to-structure-a-winnin... "SCAR", which I learned as "Situation, Consequences, Actions, Results" but the above essay will let you go deeper. Bad: "Two people stood up there, said a few words, and then everybody had cake and went…

Thanks for the detailed comment.

My target audience were the people at the conference, who are mostly long-term jj users. The topic was "Jujutsu at Google: Architecture and future plans", i.e. explaining how it works and what our plans are at Google. I'm mentioning this because I think what you're suggesting is for a different presentation, more explaining what the advantages of Jujutsu at Google are rather than how it works. My goal was not to sell the solution to this audience because they're presumably already sold on it.

Sorry if this was obvious to you and you're saying that part of my problem was that I should have chosen a different topic and/or target audience (focusing more on potential new users, perhaps).

Re: Jujutsu at Google [video]

#166

Post by 1718627440 »

steveklabnik wrote: post #108
Nashooo wrote: post #97

Earlier quoted context omitted.

I mean. How can it be scary when you have git reflog.

The reflog doesn't capture everything. jj's oplog does. An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.

The thing to keep in mind is that Git doesn't version the file system, it versions the index. This is because a file system guy like Torvalds knows that the file system is a shared resource and no program should think it can control its state. Therefore a Git repository doesn't consists out of all the files below a directory, it consists out of everything in the index.

Git does version everything that is in the repository and all these states occur in the reflog.

Re: Jujutsu at Google [video]

#167

Post by 1718627440 »

steveklabnik wrote: post #101
vlovich123 wrote: post #67

Earlier quoted context omitted.

I don’t understand this critique. You can copy a .git folder around just fine. You can expose a “server” by giving friends ssh keys that can only access the git stuff. In fact for a long time that’s how git “was done” at various corps.

> You can copy a .git folder around just fine. You can do this, but due to file locking, you can corrupt the state if it's shared. jj is specifically designed so that it won't corrupt the repo in this way: https://jj-vcs.github.io/jj/latest/technical/concurrency/

Create a bare repo on the USB stick(/dropbox/Google Drive/random folder) and just push to the USB stick.

Re: Jujutsu at Google [video]

#168

Post by martinvonz »

1718627440 wrote: post #164
stouset wrote: post #118

Earlier quoted context omitted.

Git rebase is an enormous pain in the ass. Rebases must be done linearly. And right now ! Oops, you made an error in an earlier stage of the rebase? Start over, good luck! Want to check something from earlier while you’re in the middle? Sorry, you’re in a modal state and you don’t get to use your regular git tooling.

You can just record all your changes with git commit --fixup and then do a non-interactive rebase that just applies all the changes. You can use all the regular git tools in a rebase, in fact it would be quite useless without. You can also just jump to other branches or record a fix to a previous commit. It doesn't matter what you do in the meantime, it only cares what is the HEAD, when you call git rebase --continue…

Yes, it's certainly possible to do all those things with Git. Compared to jj, it's just much harder to do, easier to mess up, and harder to recover from if you do mess up.

Re: Jujutsu at Google [video]

#169

Post by 1718627440 »

aidenn0 wrote: post #87
verdverm wrote: post #64

Earlier quoted context omitted.

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.

How do you record the specific commit of the external repository, that was used in a specific commit of your repository?

Re: Jujutsu at Google [video]

#170

Post by 7e »

I cannot wait for these big techs to ditch their Mercurial-based solutions, which are frustratingly slow and have surprisingly bad UX. Just get rid of Python completely. The more ampersands in the code for my VCS system, the better it runs.
Post reply on HN