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.
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
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: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:Cloning is portrayed as complicated?? (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