Wouldn't it be fair to say that if someone doesn't know or care about proper etiquette for public Git repositories....
I need to pause there because there is no one "proper etiquette" for public Git repositories. What makes for an appropriate level of documentation—including commit messages, documentation files, comments in code and even things like function and variable names—is entirely dependent on the target audience for that documentation, and that can vary vastly. A project with a core of full-time developers and an esoteric application domain might have very clear and efficient communication within the repo for those developers, and yet be near incomprehensible to an outsider not familiar with the application domain, the structure of the code, and the conventions and culture of that core team. That's can be fine if the "secret language" that outsiders must learn to understand the code is something that's helping the development team communicate more clearly and efficiently within the team. The developers have just made a certain choice about the balance between that clear, efficient communication within one group versus acting as a tutorial for outsiders.
Having such repos be public isn't a bad thing, nor should we be complaining that such repos don't include "beginner documentation" or tutorials (as opposed to politely suggesting that this would be helpful). It's still better to have the code available for those who
can understand it (and who may even find it worthwhile to write such beginner documentation or tutorials) than not to have it available at all.
And in many cases, perhaps such beginner documentation simply shouldn't be in that repo at all. Does every repo with some
*.kicad_{pcb,prl,pro,sch}
files in it that mystify software guys really need a detailed explanation of what KiCad is, how to download it, how to read schematics, what components are, an annotation on every pull-up resistor explaining what a pull-up resistor does, and so on?
, but they know how to use Git reasonably well, they may in fact make something not
impossible, but at least quite hard to find/recover? I'm talking about rewriting history; from
this stackoverflow question it appears that GitHub never garbage collects commits that aren't reachable from a branch, but if you do a
git clone
/
git pull
you won't get such commits.
I suspect that there
is still a reference somewhere in GitHub; I've added an answer to that StackOverflow question explaining what's going on in more detail.
But what you're talking about there isn't really an issue: that commit is "lost" because the developer who made it explicitly said that he had a different (and presumably better) version of that commit that he wanted on his `master` branch instead. So when you clone his repo, you'll get that one.
So yes, bits of history like that can get lost, in the same sense that someone can simply delete an entire project on GitHub and it's "lost," but that's just someone intentionally making something unavailable from that source, and doesn't affect "Here are the commits I do want to make available to others."