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

111–120 of 212 posts

Re: Jujutsu at Google [video]

#111

Post by Agingcoder »

Y_Y wrote: post #16
spyspy wrote: post #5

Off topic, and I don't want to knock the presenter here, but if you're ever going to give a public talk or presentation at work _please_ review the Death By Powerpoint slide deck[0] first. [0] https://www.slideshare.net/slideshow/death-by-powerpoint/855...

Ugh, I'd prefer people keep passion for the bedroom and just convey information straightforwardly without trying to "sell" it to me. Adding a false excitement signal to the information is a hindrance to me as a viewer. If you want Tony Robbins then go and see him. If you want an overview of the new product architecture lets keep calm and get on with it.

I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things.

My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home.

Now, if you’re able to indicate what’s important and not important, what’s interesting and what isn’t , and why you like it , I’ll be delighted to watch your talk.

I think it’s very difficult to be interested in something new if the presenter doesn’t seem to care about it. This is different from something written , where I expect something dry anyway.

Re: Jujutsu at Google [video]

#112

Post by verdverm »

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.

sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all)

Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those

Re: Jujutsu at Google [video]

#113

Post by baylisscg »

martinvonz wrote: post #65
pinkmuffinere wrote: post #29

Earlier quoted context omitted.

I appreciate your frank oppenness to feedback! I'd like to give you some, but first I want to call out that (1) I'm certainly no expert and (2) you may have been voluntold to make a powerpoint on material that isn't well-fit for powerpoint. My feedback: - I think you could improve by being more excited / exciting (the Death By Powerpoint slide deck says "passionate"). Personally, I try to mitigate this problem by dri…

Thanks! The presentation was mainly for the audience that was present at the conference, which was mainly people who have used jj for a relatively long time, so I think part of the problem is just a mismatch between audiences there and on YouTube. I agree about being more exciting. Not sure how to improve that :P I drink too much coffee all the time that I don't notice any difference. Harder drugs, perhaps :)

Which is fair as is not expecting everyone to be able to deliver a barnstorming talk. At least not without training.

I'd also flag that the audio is not good which isn't your fault. The trend towards conferences just pointing a camera at a lectern and throwing the footage on YouTube is unfortunate especially when it replaces circulating the slides as opposed to augmenting them. As a form of archive for attendees to review it works but not as a distribution channel.

Re: Jujutsu at Google [video]

#114

Post by verdverm »

gpm wrote: post #69
verdverm wrote: post #61

Earlier quoted context omitted.

So if I push a commit update, and then someone else pushes a commit to one I build on, and there is a conflict... How does recording the conflict, but not introducing it (if I'm understanding correctly), ... how does this affect my build/ci workflow?

If I understand you correctly we're imagining you pulled a repo with main at commit A. You added commit B on top of A. Someone else added commit C on top of A to main on the remote, and you're asking what happens? Nothing until you pull and rebase B on top of C (two distinct steps). Once B is on top of C, when B is checked out there will be conflict markers in the source tree that will presumably break your build unt…

A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches)

Let's remove the merge conflict and keep the commits in alphabetical order

B pushes a breaking change, I push a commit to C without knowing.

Are my builds and PRs now at the mercy of changes and events outside of my control?

(my hunch is that there are a bunch of confusing situations in jj like git, and that being different enough will cause user churn and people will stick with the tool they already understand the quirks of)

Re: Jujutsu at Google [video]

#115

Post by verdverm »

steveklabnik wrote: post #110
verdverm wrote: post #109

Earlier quoted context omitted.

Sounds like I still need git for much of this, so jj and the things it does is and additional thing to manage. I've been told intermixing them is not a good idea

Sure. Use the tools you like! At the same time, not everyone requires those features. All I mean to say is, the degree of support is varied out of the things mentioned, not just "no support for any of them." It's still pre-1.0 software. We'll get there :)

The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no"

I'm going to take the docs for what they say about support over an HN comment

Re: Jujutsu at Google [video]

#116

Post by gpm »

verdverm wrote: post #114
gpm wrote: post #69

Earlier quoted context omitted.

If I understand you correctly we're imagining you pulled a repo with main at commit A. You added commit B on top of A. Someone else added commit C on top of A to main on the remote, and you're asking what happens? Nothing until you pull and rebase B on top of C (two distinct steps). Once B is on top of C, when B is checked out there will be conflict markers in the source tree that will presumably break your build unt…

A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches) Let's remove the merge conflict and keep the commits in alphabetical order B pushes a breaking change, I push a commit to C without knowing. Are my builds and PRs now at the mercy of changes and events outside of my control? (my hunch is that there are a bunch of confusing situations in jj like git, and that being d…

You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it.

> iiuc jj uses stacked commits instead of branches

Locally jj doesn't really use branches, you can just create a commit on top of any other commit without creating a branch. It does represent branches (it calls them "bookmarks" for whatever reason) and pushing is pushing a bookmark to a git-branch on the remote.

> Are my builds and PRs now at the mercy of changes and events outside of my control?

I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.

Re: Jujutsu at Google [video]

#117

Post by steveklabnik »

verdverm wrote: post #115
steveklabnik wrote: post #110

Earlier quoted context omitted.

Sure. Use the tools you like! At the same time, not everyone requires those features. All I mean to say is, the degree of support is varied out of the things mentioned, not just "no support for any of them." It's still pre-1.0 software. We'll get there :)

The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no" I'm going to take the docs for what they say about support over an HN comment

You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.

Re: Jujutsu at Google [video]

#118

Post by stouset »

elAhmo wrote: post #83
qudat wrote: post #72

Earlier quoted context omitted.

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.

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.

Re: Jujutsu at Google [video]

#119

Post by stouset »

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 am (was) a git expert. I’ve written a git implementation. I’ve used it since shortly after it was first announced.

Git has lots of sharp edges that can get hairy or at least tedious really rapidly. You have to keep a ton of random arcana in working memory at all times. And a bunch of really useful, lovely workflows are so much of a pain in the ass that you don’t even conceive of doing them.

I learned jj in one day and never went back.

Re: Jujutsu at Google [video]

#120

Post by Nashooo »

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.

That makes sense
Post reply on HN