Hi Bill, On Saturday 03 September 2011, Bill Pringlemeir wrote: > I have been grappling with git for some time. People keep saying > that it has different 'models', but I could never find any sort of > discussion of what these models are [a high level overview].
What these people mean by "models" is the different organizational ways in which new code changes propagate from the original developer to the other developers and eventually into the product. These models are usually named after structures from graph theory. With centralized systems like CVS or SVN, the flow of changes is always a star: Everyone pulls from and pushes to a single central repository. You can do that with Git, but you don't have to. The Linux kernel, for example, is developed using an organizational model that is tree-shaped: Hundreds or thousands of developers contribute small changes. These changes are pulled by integrators who are experts in the field that is touched by each particular patch. After the experts collected these changes, the changes are pulled by one of a few high-level subsystem maintainers who have an interest in the patches of their particular field. In the end, Linus Torvalds pulls from these subsystem maintainers and everyone updates their code from Linus. Other models are thinkable, for example a completely deregulated bazaar without any layers or stable directions, where everyone pulls those patches that seem useful at any given moment. These models are not only about code flow. They are also models for a network of trust. You have to trust another person if you incorporate their code. With SVN, you need something like "write access" to the central repository to agree on a set of persons that everone must trust equally. With their tree model, on the other hand, Linus Torvalds only has to trust those few people he pulls from. He trusts them to choose only sources _they_ trust. There is no such thing as "write access". > Anyways, there are many new/foreign commands with git, but I think > the 'rebase' concept is an important new tool. Rebasing means automatically rewriting the latest part of your commit history so that it is based on a different parent commit. This is necessary to avoid conflicts when you pull from an integrator who changed your commits, and it is also a nice tool to make your history look cleaner before you share it. But is has not that much to do with Raphael's particular problem. Bye, Hauke ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
