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.
Basically if you want to hold commits until they're approved then you just make it so the only one who can push to the "central" repo are those in the approver role. This could of course get messy with a fast moving code base, since the approvers would inevitably have to deal with at least some of the merges, but you could have it that any non-trivial merge is punted back to one of the developers involved and has to be reapproved afterwards.
I can't imagine it being worse than having to use subversion with t
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: (Score:0)
Basically if you want to hold commits until they're approved then you just make it so the only one who can push to the "central" repo are those in the approver role. This could of course get messy with a fast moving code base, since the approvers would inevitably have to deal with at least some of the merges, but you could have it that any non-trivial merge is punted back to one of the developers involved and has to be reapproved afterwards.
I can't imagine it being worse than having to use subversion with t
Re:Cloning is portrayed as complicated?? (Score:2)
Or better: anyone can push to the central repo, but only one can push to the master branch.
You can do this kind of setup with gitolite [github.com].