6 ms·

Git is a distributed version control system. Every repo can be the master repo. 'Master' is purely a function of convention. It is worth stressing that you need

• maconic 8y ago
  Independent of Gitea (which I have nothing to do with nor have any relationship with anyone involved). Your comment "It is worth stressing that you need no software to 'host' git. Every git repository is 'self hosting', by design." worries me. Yes, technically accurate, just as notepad, webstorm, atom, vi, emacs, etc. also don't need any 'host'. If you aren't working with multiple authors, a local laptop with git plus perhaps a USB flash drive for backup is all you need. But if you plan to actually have a project that multiple people will work on, it must be hosted whether it is technically required or not IMHO :) Let's say there is no Github or Gitlab type solution... how do you send me a pull request? How do I clone your git repo? In reality, there is always a hosted repo. If you want to open your firewall and share your public IP address so that you are the "hosted" solution that I push commits to or send pull requests to then fine :) But there is always a hosted solution if there are at least two people working on the same project... whether that's gmail.com hosting your emailed zip attachments, or you opening your firewall on your laptop so other people can connect to it, etc.
  • adrianN 8y ago
    Sending patches to mailing lists is a popular way of working that is well supported by git.
    • maconic 8y ago
      Fair enough, but there is still a hosted solution, it's just hosted email instead :) I know Linux used that approach, which is seemingly ironic since Linus made git, and previously used BitKeeper. There seemed to be some problem that emailing patches to a mailing list wasn't solving to motivate the invention of git.
      • dkersten 8y ago
        You can email git patches though (which is essentially what pull requests are, really, just using a different interface)
    • tomsmeding 8y ago
      Playing the devil's advocate: then you still need somewhere that people can get the current repository state from. This place might not need to do anything with pull requests or any other write action on the repository, but somewhere to clone from is necessary. This would then be the "hosted" repo, and the patches sent via mail are just that, patches.
      • maconic 8y ago
        Exactly :)
      • pbhjpbhj 8y ago
        Sounds like you're talking around semantics. Yes, any server you connect to as a client to clone a repo is "hosting" that repo. But that can be practically any computer it doesn't need to be a _dedicated_ host in a server farm, it could be a devs laptop.
  • adam-a 8y ago
• joefreeman 8y ago
  Isn't 'origin' (not 'master') the convention you're referring to?
  • tome 8y ago
    Both "origin" and "master" are conventions. They are promoted by the tooling that gives them a sort of default status.
    • saltedmd5 8y ago
      In the context of the original post, he is referring to origin (the convention for a default remote repository), not master (the convention for a default branch).
• tjoff 8y ago
  For the vast majority of use cases centralization is an essential feature. You want that single source of truth, then you can have tons of branches etc. outside but without that single source everything falls apart if you are a team of more than one person. I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my workstation wasn't on, can't update my laptop...). Pulling code from random developers machines might sound pretty neat in isolation but that is the exception and an edge case to something else. And that something else should most likely be a centralized repository. When people say they love decentralized version control I often get the impression that what they really love is local commits. There is nothing that says that you can't have local commits in a centralized version control system, it is just that being decentralized is a neat solution for many problems. But that is just an implementation detail that very few could care about, had it not been hyped to death. Now this is something entirely different than the whole developer community putting everything in one basket (github), that's the only type of centralization worth worrying about.
  • giancarlostoro 8y ago
    Heck even torrents which are distributed needed a central server to connect through for ages. There's definitely a benefit to having a central server that aids the sea of clients / servers to communicate.
    • k__ 8y ago
      Aren't torrents using DHT?
      • tomsmeding 8y ago
        For which they need a number of central servers. These server do not do anything with the content, but they serve to announce to any new client what other clients are there, so that these new clients can start setting up their network. Once that's done, the new clients can discover the other nodes through the nodes they just connected to, and the servers have done their job. But the servers are necessary, as far as I know, unless you want to enumerate IP addresses and scan for open ports. Which is going to be interesting with IPv6.
• Boulth 8y ago
  I agree, additionally git has a built in server for sharing repos over the network. What I'd personally like to see is a repo viewer similar to Github but implemented purely in JavaScript and cloning repos in the fly just like the native git does. Git.js (https://github.com/yonran/git.js https://github.com/yonran/git.js) has something like that but it looks old and ugly.
  • hjek 8y ago
    What is this built in server git has? I thought sharing git repos over a network was depending on OpenSSH or similar.
    • Foxboron 8y ago
      git-daemon i assume. https://git-scm.com/docs/git-daemon https://git-scm.com/docs/git-daemon
    • falsedan 8y ago
      probably thinking about git-daemon (for git:// urls)
      • Boulth 8y ago
        Yes, acutely git daemon can be used to serve via http(s) too.
  • bshacklett 8y ago
    There are some real world problems with that: * Many networks limit access between wireless clients, preventing the connection between develop ER machines. * Host based firewalls often prevent services from listening on client machines. Getting security exceptions for this can be difficult to impossible in some organizations. * Discovery and initial remote config can be painful. While largely trivial from a technical perspective, this kind of thing can cause resistance from many end users. I'm not arguing against your suggestion, but these are things that need to be solved if this workflow is ever going to see mainstream adoption. Network infrastructure and security has been geared towards centralization for a long time. That's going to need to change if we want to empower distributed applications of this nature (which I believe we do).
• simias 8y ago
  The more I think about it the more I think Fossil[1] has the right approach by bundling bug tracking and wiki within the VCS. If git did the same thing (and the tools were usable) then nobody would worry about github "going bad" or anything like that. Changing your host would be as simple as changing your 'origin', anybody could replicate all the information easily. When I first heard about Fossil it sounded a bit like feature bloat but I think that was a bit of a kneejerk reaction. In retrospect I think it makes complete sense to tie code, documentation and issues. They evolve together, maybe they ought to be versioned together. [1] https://www.fossil-scm.org/ https://www.fossil-scm.org/
  • sago 8y ago
    I've mused on this in relation to github's pages sitting on the gh-pages branch: a feature I like in the abstract, though I have problems with their implementation (it seems designed to increase lock-in rather than increase flexibility). I'm not sure the VCS needs to build in those tools, but having an established branching convention for associated data could allow many flowers to bloom.
  • falsedan 8y ago
    I feel like asking a poject manager to fiddle with some SCM system to get through grooming could be a bit unreasonable. I can't see how Fossil does ticketing to see if it's PM-friendly… I feel like code reviews naturally should be stored alongside the code it's reviewing, and like the PoC shown by git-appraise from Google[0] 0: https://github.com/google/git-appraise https://github.com/google/git-appraise
• fergie 8y ago
  You’re not paranoid, and it does matter. Distributed systems definitely struggle to stay distributed. Git is a great example, as are most cryptocurrencies, which despite being distributed by design, generally come to rely on centralised wallets and trading platforms. The web itself seems to be be becoming more centralised- more people spend more time on fewer websites. Websites are increasingly being hosted on a tiny number of mega cloud services, rather than millions of independent server rooms. Centralisation is a real concern.
• ldehaan 8y ago
  use ngrok to share repos
• saltedmd5 8y ago
  The power of DVCS is in that each developer who clones a repository has a fully-functioning local repository complete with history, which can be committed to freely and seamlessly merged into the upstream later. As opposed to the traditional version control model where, e.g. every commit effectively requires a rebase against the remote and the history cannot be retrieved without a connection to the remote. The "D" in "DVCS" is about having many copies of the repository, not about having _no_ central repository, which is still a core part of having an effective delivery workflow and very much encouraged by the baked-in concept of a default remote repository. It's a distinction of technology, not of workflow. This is really a common misunderstanding about what makes DVCS an effective concept.