matheust

> Thank you, but no. I enjoy working on a branch and committing small changes at a time, sometimes trivial, sometimes not even compiling, sometimes formatting or whatever the hell I feel like. When it comes time to review, I squash all those trivial changes

I understand the workflow you've described here. I think the key word is "trivial". Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes, and that can be really bad for code archeology. When the future me or someone else wants to revisit the history and try to understand why a change was made, it may be buried down a long list of changes in a single commit, and the commit message won't be able to proper explain the reasoning behind it, IMHO.

Something that I also quite like about having individual patches in a PR/MR, is being able to review them individually too. Makes it easier for me, as a reviewer, to be able to understand the motivations behind each set of changes. But then again, that may only apply for larger patchesets/PRs/MRs...

So cool to see the types and operations being built up from lambdas! A nice brain teaser.

Interesting! I didn't know about the --remote flag and this usage. I would probably have done something like:

git clone --filter=tree:0 --depth=1 --sparse --no-checkout && git checkout HEAD <desired_file>

(But that would still end up fetching a few more objects than just the desired file.)