cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background
That's... that's... just... what?
Cloning is part of the brutally simple (and amazingly flexible) guts of git. Given Linus's hatred of C++ I think what git has become is deliciously ironic, but the basics could not be easier to understand.
Do you know if it has any sort of mechanism for holding submits until approved? We're currently using Subversion and the general consensus on that one is giving everyone their own dev branch, then having the overseer handle merging, which is tolerable for some small number of developers.
Just give every developer their own *repo*, which only they have commit rights to. It can be centrally stored on a honking great central server with a reference repo if you have loads of developers, and you're worried about space. (Of course, they can do their day-to-day work on their own repos on their own desktops/laptops if they'd rather work with a local copy, distributed vcs's are designed to be flexible that way.)
Each coherent change (one feature, one bugfix, one update) should be on a branch in their tree, for which they send a pull request (git request-pull) (after of course they've sent the patchset for review, and got some s-o-b's, ack's, or r-b's, and preferably some tested-by's too). Pull it onto a branch on your tree. If it doesn't apply, then ask them to rebase. If it passes sanity tests, then merge (which should be a fast-forward).
I maintained the linux kernel at work this way quite happily for quite a while. Had pull requests from many dozens of develpers, and the process was mostly trivial (as it was mostly scripted). The hardest part was tracking the upstream kernel, as of course failures to merge couldn't be met with "please rebase" - I had to do all the fixups myself. Fortunately, we were based on an old stable, so were relatively slow-moving.
Cloning is portrayed as complicated?? (Score:3)
cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background
That's ... that's ... just ... what?
Cloning is part of the brutally simple (and amazingly flexible) guts of git. Given Linus's hatred of C++ I think what git has become is deliciously ironic, but the basics could not be easier to understand.
Re: (Score:2)
OT, but since you seem to be familiar with git:
Do you know if it has any sort of mechanism for holding submits until approved? We're currently using Subversion and the general consensus on that one is giving everyone their own dev branch, then having the overseer handle merging, which is tolerable for some small number of developers.
Re:Cloning is portrayed as complicated?? (Score:2)
Each coherent change (one feature, one bugfix, one update) should be on a branch in their tree, for which they send a pull request (git request-pull) (after of course they've sent the patchset for review, and got some s-o-b's, ack's, or r-b's, and preferably some tested-by's too). Pull it onto a branch on your tree. If it doesn't apply, then ask them to rebase. If it passes sanity tests, then merge (which should be a fast-forward).
I maintained the linux kernel at work this way quite happily for quite a while. Had pull requests from many dozens of develpers, and the process was mostly trivial (as it was mostly scripted). The hardest part was tracking the upstream kernel, as of course failures to merge couldn't be met with "please rebase" - I had to do all the fixups myself. Fortunately, we were based on an old stable, so were relatively slow-moving.