It's Google. They are professional foot-shooters when it comes to making their offerings accessible to their audience.

Not that there are any other options. You're not gonna run datacenters on Mac boxes or Window s, nor would you want to pay a Unix vendor

Furthermore, many engineers at Google work on Macs, some even on Windows, but the actual code runs on a Linux box in a datacenter. I use a Mac, my editor is local, my terminal is local, but it's all SSH/remote to the linux box, so I've never needed jj to run on my Mac. This, or a high powered Linux desktop, are the norm.

The main exceptions to this are devs who work on iOS or macOS software, who will sometimes do local builds on their physical machine. They would benefit from jj support, but there are more hoops to jump through, and the jj port will most likely be less about running on macOS and more about jj supporting the weird ways in which source is accessed.

Yes, as in anyone can use it, you don't need special permission.

The thing to change: realizing time your audience spends reading your slides is not spent paying attention to what you say.

If you struggle with being engaging, then you want even less text on each slide so that the audience doesn't get an additional reason to tune you out.

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 drinking coffee shortly before I'm expected to be engaging. It is a drug, and for me it works.

- You could also draw the main impactful points out of the background info. The presentation you give here has a lot of deep technical detail, which is certainly of interest for the correct audience, but I think generally fits poorly in a powerpoint presentation. I think you'd generally want to focus on more high-level performance characteristics, or particularly interesting details. Perhaps a 3-4 page document would be better for this sort of deep technical material. Or maybe the level of detail is actually perfect, and I'm just not the correct audience.

I really love your response here. You seem like a great person, I think your coworkers are lucky to have you.

Not parent but I think the link is pretty clear about what they want to say. I haven't got the time to actually watch the full video, but I could tell this is not a great presentation just by randomly clicking at random timestamps. And almost any presentation from Google (technical or not) I watched on YouTube is better than this.

If you really want me to explain it for you, and just one issue:

There are way too many words on your slides.

P.S. You should click that link and go through it again. If you still don't get it, try once more.

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.

The irony the deck presents 3 very different presenters to show that you don't need to be Tony Robbins to be passionate.

If you can't be passionate, don't make it a presentation. Passionate doesn't need to mean over-the-top, but it means speaking on the topic effectively and in a way that reflects believing there's a reason for these people to sit there and listen to you.

No one is forcing people to do presentations, but once you put people in a situation where they're expected to give you their undivided attention for a block of time, those are very reasonable table stakes.

There's always blog posts, articles, mailing lists, HN posts, etc. if you don't believe there's a strong need for people to set aside time consume your information in the form of a presentation.

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.

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.

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

Easier CLI, deferred conflict resolution, megamerge workflow, an "undo" command which is like a gift from the gods.

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.

Here's what I wrote about it eight days ago: https://news.ycombinator.com/item?id=45673808

Lots of other opinions in that thread too.

It does require a google CLA.

it is literally impossible to contribute to jj without a Google account and a signed agreement with Google.

> 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?

My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.

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.

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.

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.

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

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.

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.

Even though I never found git hard, I find jj better.

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.

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.

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.

Git server is just a directory. It may or may not have actual content files in it (aka bare). In fact, any git clone of any repository is also a server on its own (and clients can have multiple "remote"s to pull from).

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.

What if we don't use git rebase at all? What does jj have to offer us?

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?

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.

LFS sorta works and submodules are just managed by git, and you can create tags with the git CLI just fine.

Hooks are a bigger change, though, for sure.