[dale_glass]

They kind of are. I mean, the hierarchical structure is mostly fictional. In git any fork is as valid as any other. This is very much unlike any SVN setup. Any of those forks could conceivably become the main one, if the former official repo died, or somebody just started developing their fork faster.

[mumblemumble]

That's what I'm getting at, though. Even though Git does support a non-hierarchical organization structure, nobody actually uses it that way.

Almost as if not every tool in search of a problem eventually finds one.

[dale_glass]

But they do. Not 100% of the time, certainly, but it very much happens.

Eg, under SVN, people would check-out our project, do some work and then either need commit rights, or create a patch.

Under git, people have full power to clone the entire thing, explore the entire history, rewrite whatever they want to, easily collaborate with other people with the same interests, and then maybe submit it all upstream.

So for instance right now in Vircadia we're having a big project of redoing the scripting engine. This work could conceivably take months, and thanks to git it doesn't have to happen in the main repo. It can happen between the people interested in that part of the code, where even several people can collaborate on a gigantic PR that would hopefully get merged in the end. SVN doesn't allow for that kind of workflow.

Yes, the high level view is still centralized, but the ability to break away from the centralization to do something big is very helpful and important. Even if it's not the dominant way of working.

[mumblemumble]

> and then maybe submit it all upstream

Right. That's typically the ultimate goal, because...

> the high level view is still centralized

Period. Just because you don't interact with the parent node in the organizational structure for a while doesn't mean it temporarily ceases to exist.