5 ms·

But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on

by evouga 4y ago

But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.

KrisJordan 4y ago
That your commits are made locally, in a clone of the entire repository, is decentralized. Your local respiratory accrues history as divergent (and unbeknownst) from upstream as you'd like it to. If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.
skybrian 4y ago
It might not be more decentralized in practice, but it's easier to make and accept outside contributions. Before "pull requests" were a thing there was the "patch" command. I don't miss manually figuring out how many directory levels to strip to get a patch to apply, or figuring out what to do when patch says "applied 7 of 9 hunks" or whatever.
sophacles 4y ago
Everyone uses it the way it was intended. There's not really another option. Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. All of that is because you have a local copy of the repo and history, and can develop your way against your local repo then push the resulting changes upstream. The fact that this allows chaining of upstreams is not the main focus of "decentralized" wrt git and the other dvcs, that's just a side effect of the concept that appealed to Linus since it would better fit the kernel development model. From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.
- COMMENT___ 4y ago
  > Everyone uses it the way it was intended. "Everyone" uses GitHub as a single source of truth, but I believe that git itself was not designed with this in mind. GitHub users use git as centralised version control with "local commits, rebases or whatever". > Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. I think that it is possible to add local branches and commits to centralised version control. Will it make it decentralised? I don't think so. > From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments. It's not a topic of "horses vs cars" you know. Not even close. This analogy is a plain trolling IMO.
  - kfkdldldl 4y ago
    > I think that it is possible to add local branches and commits to centralised version control Well, you think wrong, because it's not. Centralized change control will contact the central server for every change. If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reachable over the network
    - COMMENT___ 4y ago
      I believe that - hypothetically - centralised version control can have disconnected local commits with private local branches. But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI. I don’t think that SVN, p4 or CVS have support for local commits. What I want to say is that local commits could be added into centralised version control systems. Come on, SVN has a local working copy. Won’t it handle local commits?
deleted 4y ago
[deleted]
atq2119 4y ago
> Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to. The company I work for has internal forks/clones of many projects hosted on GitHub. I routinely interact with at least four different clones of a project: the upstream one on GitHub; the local one on my machine; my personal clone on GitHub for upstream contributions; and the company-internal clone hosted on some company-internal server. So yes, we are using git in a decentralized fashion.

by evouga 4y ago

KrisJordan 4y ago

That your commits are made locally, in a clone of the entire repository, is decentralized. Your local respiratory accrues history as divergent (and unbeknownst) from upstream as you'd like it to. If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.

skybrian 4y ago

It might not be more decentralized in practice, but it's easier to make and accept outside contributions. Before "pull requests" were a thing there was the "patch" command. I don't miss manually figuring out how many directory levels to strip to get a patch to apply, or figuring out what to do when patch says "applied 7 of 9 hunks" or whatever.

sophacles 4y ago

Everyone uses it the way it was intended. There's not really another option. Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. All of that is because you have a local copy of the repo and history, and can develop your way against your local repo then push the resulting changes upstream. The fact that this allows chaining of upstreams is not the main focus of "decentralized" wrt git and the other dvcs, that's just a side effect of the concept that appealed to Linus since it would better fit the kernel development model. From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.

COMMENT___ 4y ago
> Everyone uses it the way it was intended. "Everyone" uses GitHub as a single source of truth, but I believe that git itself was not designed with this in mind. GitHub users use git as centralised version control with "local commits, rebases or whatever". > Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever. I think that it is possible to add local branches and commits to centralised version control. Will it make it decentralised? I don't think so. > From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments. It's not a topic of "horses vs cars" you know. Not even close. This analogy is a plain trolling IMO.
- kfkdldldl 4y ago
  > I think that it is possible to add local branches and commits to centralised version control Well, you think wrong, because it's not. Centralized change control will contact the central server for every change. If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reachable over the network
  - COMMENT___ 4y ago
    I believe that - hypothetically - centralised version control can have disconnected local commits with private local branches. But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI. I don’t think that SVN, p4 or CVS have support for local commits. What I want to say is that local commits could be added into centralised version control systems. Come on, SVN has a local working copy. Won’t it handle local commits?

deleted 4y ago

[deleted]

atq2119 4y ago

> Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to. The company I work for has internal forks/clones of many projects hosted on GitHub. I routinely interact with at least four different clones of a project: the upstream one on GitHub; the local one on my machine; my personal clone on GitHub for upstream contributions; and the company-internal clone hosted on some company-internal server. So yes, we are using git in a decentralized fashion.