git "philosophy" understanding problems - no central server?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
git "philosophy" understanding problems - no central server?
Hi,
I was reading Git User's Manual and I was wondering about one passage.
Quote:
Setting up a shared repository
[...]
However, while there is nothing wrong with git's support for shared repositories, this mode of operation is not generally recommended, simply because the mode of collaboration that git supports—by exchanging patches and pulling from public repositories—has so many advantages over the central shared repository
[...]
I don't see these advantages. OK, you can still work even if your Server is down, but if you have *no* central server to share the development, then what?
How to apply all these changes? Don't tell me, that, for example, Linus Torvalds sits days and nights by filtering and applying new patches he received?
I mean, there are several Kernel git repos available.
I was reading Git User's Manual and I was wondering about one passage.
I don't see these advantages. OK, you can still work even if your Server is down, but if you have *no* central server to share the development, then what?
How to apply all these changes? Don't tell me, that, for example, Linus Torvalds sits days and nights by filtering and applying new patches he received?
I mean, there are several Kernel git repos available.
Can somebody explain this please?
Thanks
Why at all applying changes requires a central server ?
You have a tree and you apply changes to that tree, thus producing an updated tree. What does a server have to do with this ?
The fundamental issue is not GIT, it is personal responsibility and traceability.
I.e. despite the fact that the wide-spread approach is that every programmer on a project can apply changes and then nobody knows who screwed up it's a horrendously wrong approach.
The right IMO approach is that there is personal responsibility. This means that there is a person responsible for the integrity of project tree (and I used to be such a person on a number of VLSI projects). The responsibility implies that either the responsible person makes all the changes or he/she approves of all the submitted changes.
I.e. there is a simple technical part of applying the change and there is a part requiring human intelligence, and that part requires human understanding of the proposed changes.
So, again, no server is necessary and in this case Linus and other key Linux people are the ones who apply changes after analyzing them.
Honestly, it sounds like a lot of work. But okay; you have good arguments.
So http://git.kernel.org/ for example, exists only to distribute the branches after Linus decided which patches come into it's trees?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.