3 ms·

> I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). You're confusing a hosting service with

> I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). You're confusing a hosting service with being forced to use a centralized repository. Take GitHub, for example. If git was centralized them you would not have forks, multiple remotes or multihosting, or could even work independently of the remote server. With Git, you can even set up a repo in a network file system somewhere, or even a USB thumbrive.

hinkley 7y ago
Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.
- rumanator 7y ago
  Git does far more than making it easy to fork: it makes it trivial and inexpensive. Meanwhile SVN supports forking in the sense that it supports copying directories.
  - xorcist 7y ago
    The "fork" concept is not native to neither Subversion nor git. You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time. Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely considered an easy user interface. Everything is a file and all that. In comparison, git users must learn the git object naming scheme, otherwise things can end up very confusing should you have a directory and a branch with the same name.
    - wtetzner 7y ago
      > They are a bit more convenient in git since they are created in constant as opposed to linear time. I would argue that branches are nicer in git because it makes merging so much easier.
    - rumanator 7y ago
      > You are probably thinking of branches and tags, No, I was referring to forking projects, in the sense that Git allows for creating brand new and independent repositories that clone the version history up to a point in time and enable to add the origin Git repository as a remote repository. SVN also does not support branching or tagging, as it actually supports only copying directories around a file system.

hinkley 7y ago

Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.

rumanator 7y ago
Git does far more than making it easy to fork: it makes it trivial and inexpensive. Meanwhile SVN supports forking in the sense that it supports copying directories.
- xorcist 7y ago
  The "fork" concept is not native to neither Subversion nor git. You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time. Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely considered an easy user interface. Everything is a file and all that. In comparison, git users must learn the git object naming scheme, otherwise things can end up very confusing should you have a directory and a branch with the same name.
  - wtetzner 7y ago
    > They are a bit more convenient in git since they are created in constant as opposed to linear time. I would argue that branches are nicer in git because it makes merging so much easier.
  - rumanator 7y ago
    > You are probably thinking of branches and tags, No, I was referring to forking projects, in the sense that Git allows for creating brand new and independent repositories that clone the version history up to a point in time and enable to add the origin Git repository as a remote repository. SVN also does not support branching or tagging, as it actually supports only copying directories around a file system.