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.
You have complete control over what goes into your repository. Off the top of my head, I'd have a repository for submitters to push to and another one only you have write access to, into which you can pull anything you want and which you can all agree to call the "official" repository of approved commits.
Nowhere is it written developer branches must be pushed anywhere. What goes on in their own repos is really nobody else's business, because see above: nobody has to take or keep anything they don't want. Do take the time to learn how the object db, blobs and trees and commits, is structured, and the thumbs into that db. If you're like me, once you see it you'll have the itch to dink with the innards with shell commands just because it's so ridiculously easy. Build from there until you understand the low-level commands, and after that you'll see all the rest as merely conveniences for common tasks, which is what they are. For my money, any other route to understanding git is like trying to learn math without understanding equality.
The only thing I think painful about it is all of the freaking URLs you have to use all over the place.. Then again, I'm comparing it to the mostly easier cvs⦠and from a currently non-git user point of view, you go from rev #s in cvs to big URLs in svn to completely incomprehensible long hex #s in git. But at least I seem to have fewer merge conflicts with svn than I do with cvs.
Recently as in when? I've been using svn for at LEAST a few years, and it's been the same as long as I've been using it.
svn merge -c NUM URL is what I use the vast majority of the time.
I still don't know what you mean by "painful", unless it means merge conflicts.. and as I said in my original reply, at least anecdotally, I saw merge conflicts far less often in svn than cvs⦠and I say this as someone who prefers cvs.
Other source control systems parse the code to detect methods that have moved around. This makes merging even easier, since if all you did was move a method, or add some whitespace, it will notice that it's not really a conflict. Th
You haven't been using it long enough so. There was a point in time were svn supported using merge but failed to record any information about what had been merged to where. So if your repeated the operation, you got a giant clusterphuck of a result. Same thing applied to subsequent merges, since there was no information stored in subversion you had to know beforehand which revisions were previously merged.
The consequence of this was that many teams ended up having to create custom tools to perform the mer
Gerrit is a code-review tool for git -- you submit your changes to gerrit, it holds them until they are code reviewed and approved, then they get passed into the central repo. You can configure it so that one person (or a small subset) is a required gatekeeper for passing things to the central repo, or so that it requires some number of "yes" votes from reviewers to be approved.
It gives a very nice web front end for diffs and comments when doing code reviews, t
You can also do it the same way you do with subversion though in which everyone has commit/push access to the same repo and just create a lot of branches.
And obviously you can mix the two methods just fine.
Yeah, don't pull them into your branch! It takes a bit to get used to, but your brain gets knocked straight eventually;)
Seriously though, ENORMOUS projects with thousands of submitters are using Git effectively. Most of the larger projects use a "lieutenant" based system where the head of the project has several trusted sources that he/she pulls from. The lieutenants are able to divide up the pull requests and each test/integrate a portion.
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
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:Cloning is portrayed as complicated?? (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:1)
Re: (Score:2, Informative)
Sounds like you may want gerrit [google.com].
If you can't tell from the doc, check out this video [bandlem.com].
Re: (Score:2)
I would have called it Stupid Git.
Re: (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].
Re:Cloning is portrayed as complicated?? (Score:4, Interesting)
You have complete control over what goes into your repository. Off the top of my head, I'd have a repository for submitters to push to and another one only you have write access to, into which you can pull anything you want and which you can all agree to call the "official" repository of approved commits.
Nowhere is it written developer branches must be pushed anywhere. What goes on in their own repos is really nobody else's business, because see above: nobody has to take or keep anything they don't want. Do take the time to learn how the object db, blobs and trees and commits, is structured, and the thumbs into that db. If you're like me, once you see it you'll have the itch to dink with the innards with shell commands just because it's so ridiculously easy. Build from there until you understand the low-level commands, and after that you'll see all the rest as merely conveniences for common tasks, which is what they are. For my money, any other route to understanding git is like trying to learn math without understanding equality.
Re: (Score:3)
What you should be doing is giving each substantial unit of change a branch.
Personal branches become fiefdoms. Unless the developer concerned is disciplined, you are in effect creating a bunch of forks.
Make a branch for each feature, bugfix, etc. It helps that the most painful thing about SVN, merging, is so much easier in Git.
Re: (Score:2)
Why do you call merging painful in svn?
The only thing I think painful about it is all of the freaking URLs you have to use all over the place.. Then again, I'm comparing it to the mostly easier cvs⦠and from a currently non-git user point of view, you go from rev #s in cvs to big URLs in svn to completely incomprehensible long hex #s in git. But at least I seem to have fewer merge conflicts with svn than I do with cvs.
Re: (Score:2)
Re: (Score:2)
Recently as in when? I've been using svn for at LEAST a few years, and it's been the same as long as I've been using it.
svn merge -c NUM URL
is what I use the vast majority of the time.
I still don't know what you mean by "painful", unless it means merge conflicts.. and as I said in my original reply, at least anecdotally, I saw merge conflicts far less often in svn than cvs⦠and I say this as someone who prefers cvs.
Re: (Score:2)
It is possible the reason you don't have problems with SVN merge and I did was because you use the command line and I use tortoise. I'm not the only one who thinks it's painful, though [assembla.com].
Other source control systems parse the code to detect methods that have moved around. This makes merging even easier, since if all you did was move a method, or add some whitespace, it will notice that it's not really a conflict. Th
Re: (Score:1)
The consequence of this was that many teams ended up having to create custom tools to perform the mer
Re: (Score:3, Informative)
http://en.wikipedia.org/wiki/Gerrit_(software)
Gerrit is a code-review tool for git -- you submit your changes to gerrit, it holds them until they are code reviewed and approved, then they get passed into the central repo. You can configure it so that one person (or a small subset) is a required gatekeeper for passing things to the central repo, or so that it requires some number of "yes" votes from reviewers to be approved.
It gives a very nice web front end for diffs and comments when doing code reviews, t
Re: (Score:2)
https://help.github.com/articles/using-pull-requests [github.com] works well when you let everyone have their own "fork" but afaik wouldn't work for a single shared repository.
You can also do it the same way you do with subversion though in which everyone has commit/push access to the same repo and just create a lot of branches.
And obviously you can mix the two methods just fine.
Re:Cloning is portrayed as complicated?? (Score:4, Insightful)
Seriously though, ENORMOUS projects with thousands of submitters are using Git effectively. Most of the larger projects use a "lieutenant" based system where the head of the project has several trusted sources that he/she pulls from. The lieutenants are able to divide up the pull requests and each test/integrate a portion.
Re: (Score:2)
Each coherent change (one feature, one bugfix, one update) should be on a branch in their