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.
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 merge and record the information somewhere else, or require that developers recorded which revisions were merged in the commit message.
The subversion developers eventually realised their mistake and added internal metadata to handle, so that if you merged r100 of branchA to branchB, and then subsequently tried to merge r200 of branchA to branchB, subversion would realise that everything prior to, and including r100 on branchA was already merged, and it need only merge the differences between r100 and r200.
Oddly enough though, by then most devs had already abandoned it for just about anything else that had sane merging.
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: (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:Cloning is portrayed as complicated?? (Score:1)
The consequence of this was that many teams ended up having to create custom tools to perform the merge and record the information somewhere else, or require that developers recorded which revisions were merged in the commit message.
The subversion developers eventually realised their mistake and added internal metadata to handle, so that if you merged r100 of branchA to branchB, and then subsequently tried to merge r200 of branchA to branchB, subversion would realise that everything prior to, and including r100 on branchA was already merged, and it need only merge the differences between r100 and r200.
Oddly enough though, by then most devs had already abandoned it for just about anything else that had sane merging.