61–65 of 65 posts
Earlier quoted context omitted.
While I agree this guide is great, I think opinionated and correct are mutually exclusive.
"...opinionated and correct are mutually exclusive." TIMTOWTDI.
Earlier quoted context omitted.
Man, sounds like the complete opposite experience to me. Going from SVN to even a centrally controlled Git repo is a breath of fresh air. I recently switched a project from Darcs to git. It was (again) mostly centrally contained, despite being a DVCS. And Darcs being DVCS, we held out on switching to Git since it seemed like it wouldn't really be that much of an improvement. In other words, change for change sake. Bo…
What are the improvements of using git over darcs? Do you miss anything from darcs?
The first thing we did after converting the Darcs repo to Git was to run a complicated rebase script that split all the dev repo patches into logical git branches. If you looked at the Git repo at that point it would be a single linear set of commits which then explodes into 14 or 15 different branches all at the same point.
Since then we've been using feature branches to do our development and Git really helps to keep distractions to a minimum. "git stash" and feature branches mean that random stuff I am trying is filed away neatly and doesn't pollute my working directory like it did when we were Darcs based.
Honestly I don't really miss anything from Darcs. I could fib and say Darcs's cherry-picking is better than Git's, but while that's true, I don't really cherry pick much in Git (it's usually only to fix accidental checkins on the wrong branch) and so I don't hit conflicts often (at all, really).
Darcs allowed us really simple deployment (we'd just push our patches to the live server—not the cleanest, but oh so easy). Git required us to write a hook that deploys when we push to the production branch. However, that was actually a blessing in disguise, since now the hook can do good stuff like reload the server when the code changes and rebuild static assets as appropriate. We used to just do that by hand.
git is only good for people that was working like Linus. if you didn't have been accepting patches by email but instead had a fluid svn, perforce, etc central repository and people already collaborating with commit powers, then if you move to git "just because" (which is the reason of 99% migrations) you're going to have a bad time. sadly, my company decided to move just to use pull requests as a poor man's code revi…
Sounds more like resistance to change than anything wrong with Git. I used perforce at my previous company, and while Git's learning curve was higher, I definitely see the advantages of a distributed version control system over a centralized one: 1. Not having to check out files means I can work offline. 2. When working on multiple features, it's much easier to create a new Git branch than it is to create a new Perfo…
i known it's the open source favorite. because it solve that problem.
for me all my corporate projects where in hg before git became a fad. but i guess I'm afraid of change/can't read a manual.
"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
Mine, too. Fortunately, mercurial has that feature, too. (Though you might need a plugin.)
Earlier quoted context omitted.
Sounds more like resistance to change than anything wrong with Git. I used perforce at my previous company, and while Git's learning curve was higher, I definitely see the advantages of a distributed version control system over a centralized one: 1. Not having to check out files means I can work offline. 2. When working on multiple features, it's much easier to create a new Git branch than it is to create a new Perfo…
love how git people like to shout "afraid of change" i known it's the open source favorite. because it solve that problem. for me all my corporate projects where in hg before git became a fad. but i guess I'm afraid of change/can't read a manual.
Only when you don't give any substantive reasons and just talk about how difficult it is. It just seems difficult because it's a different way of thinking.
>>i known it's the open source favorite. because it solve that problem.
So you do agree that it solves a real problem, it isn't just a fad. Also, a lot of companies like to attract good talent by open sourcing some of their internal libraries. Since they'll be using git for that anyway, makes sense to use git as their main VCS.
>>but i guess I'm afraid of change/can't read a manual.
You're taking this way too personally. I'm just saying give it a fair shot and come up with objective problems with it. No one will take you seriously with "I don't like it because it's too hard". You're better than that.