On Wed, Nov 16, 2022 at 03:55:54PM +0400, Konstantin Khomoutov wrote: [...] > I think the key problem impeding understanding of this (you're certainly not > alone on this) is that provided how 99.9% of tutorial material on DVCSes is > written, many people maintain that if there is a network of DVCS repos > communicated with each other, they all essentially are just replicas of > _logically the same thing._ > This is where the problem lies, because Git does not make this assumption. [...]
Moreover, most people almost inevitably arrive at the conclusion that such a network of connected repos is necessarily star-shaped: at the center is a "central" repo everyone fetches from and pushes to, and it is surrounded by its clones, in which folks do their work, and this work is shared only via pushing to that central repo. With this mindset, it is indeed can be mind-boggling to hear that a branch named "feature" fetched from a remote repository might something completely unrelated to the branch named "feature" in your local repository. I don't know about Hg, but Fossil (a DVCS I have a sweet spot in my heart for, even though most of its design decisions are diametrically opposite to those of Git) even had an UUID embedded into each repository, and would check that UUID presented by a remote repository you were to communicate with is equal to that if yours, and it it isn't, the operation would be aborted because the repos were thought to contain conceptually different stuff. Git has a stance opposite to this, and this is reflected in how it handles branches. (BTW since then Fossil gained a knob allowing you to switch these checks off). Git supports the star-shaped networks but that was never a goal. In contrast, Linux - the project to help develop which Git was created - has a hierarchical structure, where each kernel subsystem has its own _set_ of repos, and the project lead fetches branches with "graduated" stuff from those repos to merge them, and then publishes the results. Many Linux devs routinely use "triangular workflow", when they fetch updates from an upstream project but push them to their own fork (separate repo). The overview of some of the more popular workflows can be seen in [1]. 1. https://git-scm.com/book/tl/v2/Distributed-Git-Distributed-Workflows -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20221116163002.essxiu5w5dofb52y%40carbon.
