Seconding this opinion: Dwarkesh's podcast is really good. I haven't watched all of the Zuck interview but I recommend others to check out a couple extra episodes to get a more representative sample. He is one of the few postcasters who does his homework.
Whoops! I should have fact-checked that: I had it in my head that it was recent based on there being so much recent discussion of it online. I've updated the post
In the next release we're adding worktree support: if you use worktrees in your daily flow I'd love to know what that flow looks like and what your pain points are so feel free to join the discussion here: https://github.com/jesseduffield/lazygit/discussions/2803
Thanks for the feedback, I've been slack on documentation as more features have been added. Do you have a preference for tutorials? e.g. video or text?
Lazygit maintainer here: I've found myself in your shoes quite a bit (without the commit signing part) and a few weeks ago I put up a draft PR where if a file is selected, it highlights the commits that touch that file. Typically you want to amend the most recent commit that changed the file and typically that commit is visible without needing to scroll. But I haven't spent much time thinking about what the ideal UX is, how to activate it, etc.
I address this point in the post but I'll summarise here: Your argument is equally applicable to higher levels of encapsulation. If you have a class which is private to a package, then code coverage tells you nothing about whether that class is actually used in your package's public API. If you have a package which is private to some parent package, you're in the same situation. You can follow this all the way up to the binary output of an application and say that unless you're doing end-to-end tests which capture user keystrokes and mouse clicks, you're breaking encapsulation (you can make the same argument for a large library).
We choose not to run only end-to-end tests because it's expensive both in terms of writing the tests and running them. We choose not to run only unit tests at the lowest possible form of encapsulation because they're more likely to need rewriting when we refactor. Instead we pick out abstractions at various levels of encapsulation that warrant testing in isolation. The decision on whether to test a private method or a private class or a private package differs only in degree, not in kind.
To convince those who disagree with you, you'll need to make a case for why private methods should in fact be held to a different standard than other levels of encapsulation. I'm open to being persuaded on this point but I can't think of an argument that convinces me.
Code coverage covers package private classes too just like it covers public methods. When I say public I mean public. Parent class too...
Yes. Ideally you want high coverage of integration tests. If you're going for best quality then sure. The high coverage of unit tests is valuable since we don't want to fail on integration tests. We want to fail on unit tests (easier to trace the failure, faster to run).
Private methods by definition are not an abstraction. Testing them makes absolutely no sense. They are either reachable or they are not.
The one reasonable argument is that it's hard to create a synthetic test that will reach some private methods. That's a valid claim but that's why writing tests is hard. Going directly to the private method is "cheating" and will cause code rot since again, it breaks coverage.
This goes beyond private methods. Say a branch is never reached through a public interface but you test it in your unit tests since you don't know. This aspect is completely hidden from you.
> To convince those who disagree with you, you'll need to make a case for why private methods should in fact be held to a different standard than other levels of encapsulation. I'm open to being persuaded on this point but I can't think of an argument that convinces me.
Encapsulation literally defines this as a core principal. If you don't accept that then you don't accept the most important concept of OOP.
You're thinking about this in the wrong direction. If you want to break encapsulation you need to come up with an argument that's better than: "It's easier for me in this specific case".
> Private methods by definition are not an abstraction.
A private method is indeed an abstraction. If you take a chunk of code and extract it out into a method, that's an abstraction, regardless of whether it's private or not.
> Say a branch is never reached through a public interface but you test it in your unit tests since you don't know. This aspect is completely hidden from you.
This is purely a tooling problem. There is no good reason why your linter can't flag that a private method is unused in non-test code.
> Encapsulation literally defines this as a core principal. If you don't accept that then you don't accept the most important concept of OOP.
Do you have a source evidencing this claim? I would be surprised to find any canonical source stating that private methods should be held to a different standard to private classes and private packages
> If you want to break encapsulation you need to come up with an argument that's better than: "It's easier for me in this specific case".
My argument is this: we 'break' encapsulation every time we write a test that's not end-to-end. The question is how much we want to break it, and that question depends on how stable and well-defined the abstraction is that we want to test. If a private method is stable and well-defined, and if the cost of extracting it out into its own class is too great, then it's appropriate to test. A private method is less likely to be stable and well defined compared to a class or a package, because it's at the bottom of the encapsulation hierarchy, but it is not fundamentally different to other levels of encapsulation, and therefore there will be times when it is appropriate to test.
After some thinking, I now see what you were talking about wrt code coverage, however again the same argument can be applied to higher levels of encapsulation and it's not obvious private methods are special.
