Is it? If I checksum the .git folder on my workstation and my co-workers workstation they're going to come back different. There's no guarantees that I haven't rebased main, or that I have all of the branches that were stored on the remote. If something catastrophic happens to our main remote, which one of our versions do we restore to?
> It's decentralized version control.
Just because git is decentralised, doesn't mean that it can only be used in a decentralised way. How many teams are pushing/pulling like a p2p network, and deploying to servers/clients from their workstations and verifying that the commit hash of their local repository matches what's deployed? A vanishingly small number of people.
> Most of the things you're struggling to solve are effectively preventing it from actually working as intended
If everyone is using it wrong, the tool is wrong. There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed. Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you.
> There's no guarantees that I haven't rebased main,
You may have rebased your local main branch, but that doesn't affect your origin/main reference.
> or that I have all of the branches that were stored on the remote.
Everytime you pull or fetch, you get all the branches stored on the remote. Of course, you're not going to have any branches that were added after the last time you communicated with the remote.
> If something catastrophic happens to our main remote, which one of our versions do we restore to?
Who is to say that my origin/main is the same as your origin/main, or that my origin is the same as what our running application is using as it's origin?
> Of course, you're not going to have any branches that were added after the last time you communicated with the remote.
Exactly, so you're relying on the fact that _someone_ has the latest version without actually verifying it.
I believe the core of your argument is that GitHub and GitLab provide more than just git DVCS. I don't think anyone argues with that.
However, this core argument is obscured by a very emotional rejection of what the parent is saying - that you don't always need these additional things, and that you can (sometimes? often?) keep things simple. I think that's an interesting point to discuss.
> If something catastrophic happens to our main remote, which one of our versions do we restore to?
Dunno, talk it through? I hope you have a good enough relationship with your coworker that you can discuss your work with them.
> Just because git is decentralised, doesn't mean that it can only be used in a decentralised way
The OP not only did not say git can only be used in a decentralised way, they actually mentioned a git server - ie. a central point.
> There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed.
Nobody argued otherwise. But, it is also true that there are billion-dollar companies out there that use an internal git service. How do I know that? Both GitHub and GitLab sell on-premises versions to those types of companies :)
> Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you.
Rationally, this argument is so off it can only be result of an emotional outburst. OP never mentioned sharing patches over mailing lists, and has in fact stated that it's easy to host git server.
I understand and respect your argument and agree GitHub, GitLab and others provide valuable service. But gees, chill out, man. https://xkcd.com/386/
> You don't always need these additional things, and that you can (sometimes? often?) keep things simple. I think that's an interesting point to discuss.
Agreed, however in my experience advocates for this kind of simplicity "don't need" these things, except they ad-hoc rely on piecemeal solutions.
> Dunno, talk it through? I hope you have a good enough relationship with your coworker that you can discuss your work with them.
This works on a team of 2. On a team of 10/20/50/100, pausing everything for everyone to figure out seems like a terrible idea. And teams of 2 quickly become teams of 10.
> they actually mentioned a git server - ie. a central point.
But they ignore all of the overhead of running a server, and fall back on it being decentralized as a solution to the "problems" of runnign a server.
> Rationally, this argument is so off it can only be result of an emotional outburst.
I'd really rather you didn't stoop to personal attacks on me, especially as I've done nothing of the sort.
> OP never mentioned sharing patches over mailing lists, and has in fact stated that it's easy to host git server.
OP said in his comment "Most of the things you're struggling to solve are effectively preventing it from actually working as intended. ". Given that git was designed for the linux kernel [0], a reasonable criticism of "working as intended" is criticising the workflow it was designed around. Running a git server doesn't give you _any_ way to collaborate or work with people, you need to build all of that tooling on top of it. The linux kernel uses patches distributed by email, despite hosting a git server.
I disagree on many points here, but I don't think either of us is going to convince the other.
Instead, I'll just apologize: I'm sorry if my comment came across as an attack. I didn't mean it as such. I've seen too many flamewars over trivialities.
Is it? If I checksum the .git folder on my workstation and my co-workers workstation they're going to come back different. There's no guarantees that I haven't rebased main, or that I have all of the branches that were stored on the remote. If something catastrophic happens to our main remote, which one of our versions do we restore to?
> It's decentralized version control.
Just because git is decentralised, doesn't mean that it can only be used in a decentralised way. How many teams are pushing/pulling like a p2p network, and deploying to servers/clients from their workstations and verifying that the commit hash of their local repository matches what's deployed? A vanishingly small number of people.
> Most of the things you're struggling to solve are effectively preventing it from actually working as intended
If everyone is using it wrong, the tool is wrong. There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed. Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you.