3 ms·

> 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 min

> 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?
  - sophacles 4y ago
    I think you are getting confused about what is decentralized by git (et al). It's not that there's a notion of "a canoncial copy". The canonical copy stuff is about user/developer organization. What dvcs distributes is the history - the notion that you can have local commits, branches, etc is a decentralization of a repo's history. In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. The fact that you keep coming back to github to "prove" it's somehow centralized at the vcs level is clearly you just doing some contrarian trolling.
    - COMMENT___ 4y ago
      > In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy? I think that the most common daily use workflows with git and GitHub are absolutely centralised regardless of the decentralised nature of git. * I have a local git repository, its local version history and all the great features this provides. But I have to push to GitHub, you know. Can I somehow publish my changes if GitHub is down? So how is this different from centralised version control? * GitHib provides extra features besides version control. It has a bug tracker, wiki, whatever. I'm tied to all these features, and they are not decentralised at all. I understand that this analogy is silly, but GitHub is a well done SourceForge with Git. But it's still SourceForge, and it's centralised. When I use git with GitHub, I usually only clone, commit and push and check my project's issue tracker. All these actions except commit require access to GitHub. So I think that the workflow is absolutely centralised even if git is decentralised by design and has local version history. I think that's what @evouga meant in his comment above when he said > 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.
      - deleted 4y ago
        [deleted]

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?
- sophacles 4y ago
  I think you are getting confused about what is decentralized by git (et al). It's not that there's a notion of "a canoncial copy". The canonical copy stuff is about user/developer organization. What dvcs distributes is the history - the notion that you can have local commits, branches, etc is a decentralization of a repo's history. In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. The fact that you keep coming back to github to "prove" it's somehow centralized at the vcs level is clearly you just doing some contrarian trolling.
  - COMMENT___ 4y ago
    > In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy? I think that the most common daily use workflows with git and GitHub are absolutely centralised regardless of the decentralised nature of git. * I have a local git repository, its local version history and all the great features this provides. But I have to push to GitHub, you know. Can I somehow publish my changes if GitHub is down? So how is this different from centralised version control? * GitHib provides extra features besides version control. It has a bug tracker, wiki, whatever. I'm tied to all these features, and they are not decentralised at all. I understand that this analogy is silly, but GitHub is a well done SourceForge with Git. But it's still SourceForge, and it's centralised. When I use git with GitHub, I usually only clone, commit and push and check my project's issue tracker. All these actions except commit require access to GitHub. So I think that the workflow is absolutely centralised even if git is decentralised by design and has local version history. I think that's what @evouga meant in his comment above when he said > 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.
    - deleted 4y ago
      [deleted]