A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it.
Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).
> Atomicity accross projects
Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn't Git.
> Package management
Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
> Semantic diff
This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
> Merge queue data structure
The body of this bullet doesn't relate to the heading. I guess they're talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.
> Fan-out pull requests
Github is not Git.
> git should be fully decoupled from the pull request and merge workflow
Oh dear. Where is Drew Devault...
> lfs
The first good point they've made
> fossil
Yes fossil is cool. If the title of the post was "we should all use fossil" it would be more realistic.
> Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
I agree with this point, but maybe using the cryptographic hashes from a VCS is better than a checksum? Other than that, I don't think there's any reason to tie the two together.
> This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
Actually, not really a gargantuan undertaking. Large, yes, but that's only to tell the VCS about the semantics of each language. The actual algorithms to do so are pretty small, and the semantics needed for each language consists of a lexer and some dumb knowledge about the structure, i.e., what a function looks like, what a type definition looks like, etc. Source: I am designing those algorithms right now.
Other than that, I agree with your points, except that I'm now making a competitor to fossil. :)
Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).
> Atomicity accross projects
Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn't Git.
> Package management
Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
> Semantic diff
This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
> Merge queue data structure
The body of this bullet doesn't relate to the heading. I guess they're talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.
> Fan-out pull requests
Github is not Git.
> git should be fully decoupled from the pull request and merge workflow
Oh dear. Where is Drew Devault...
> lfs
The first good point they've made
> fossil
Yes fossil is cool. If the title of the post was "we should all use fossil" it would be more realistic.