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 review tool. sigh. I'm the 99%
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 Perforce workspace.
3. People really tend to abuse Perforce's 'lock file' feature. I'm glad this isn't possible in Git.
4. I haven't really noticed any drawbacks to the pull-request feature. You can still review and comment on diffs on Github.
5. It's the version control of choice for open source software, so if you use any third-party libraries (and I hope you do!), you'll probably need to know how to use Git anyway.
I can't really think of anything I miss from Perforce.
Edit: these advantages are not specific to Git, but any distributed version control system. If you find Git to be too difficult, don't worry, it's not the only game in town. I've heard Mercury is much easier to pick up. Good luck!
>>love how git people like to shout "afraid of change"
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.
Why would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.
> When did using git-based package managers become the norm?
I'm a web developer, so my response was hastily written thinking about my own narrow scope. I'm sure that non-web developers can go their whole lives without interacting with git, but it's impossible for web developers.
Npm (Node), Composer (PHP), and Bower (web) package managers all use git (and often GitHub itself) pretty religiously. I know that one or more of those may support other VCS repos, but git is the de facto flavor.
> Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts?
Not exactly. First of all, that's what I _used_ to do before every language had its own package manager.
Second, I do use versioned releases. However, I use the tagged versions that are determined by the author(s) of the library. I'm not just pulling down a bleeding-edge, un-tested library, and I don't get every single commit.
> 2. Download the library using a web browser, and just put it where it needs to be.
That might work for certain projects, but let's say you're using 10 third-party libraries. If they're under active development, you can expect at least a few security updates between the time you first import them and the time you ship your own product.
It's not very practical (especially for a programmer!) to keep manually checking your dependencies' product pages for updates.
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.
Boy was I wrong. Even that change was refreshing. I find Git to be an absolute pleasure to use (and as a plus it stole all the good Darcs interface features). Git made managing our release branch fun again. The thing I like about Git is that it's low level enough that you can make it do anything.
Like the time I foolishly changed the EOLs on upstream code after I committed it—Git let me track my changes and merge in new upstreams, despite every line in the new upstream being different. Yay, git.
Darcs doesn't support branches—it's just a collection of patches in every repo. Our Darcs project was set up with a "dev" repo where we'd dump everything and then promote patches to "beta" repo and then the "production" repo. The downside was that "dev" was filled with a lot of dead end patches that needed finishing/fleshing out before they could go to production. In git, those are now on separate branches and so the main development line is much cleaner. We could have done that with Darcs, but it would require multiple repos (one for each branch), both on the server and on our development machines (yuck).
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.
If working like Linus means using git, then I'd say his is a better way to work. Speaking for myself, there's no reason I can see to ever go back to svn. Even for personal single-dev projects.
It is so simple to create a new git repo on the fly, with no need for a separate repository location. And rebasing plus easy branching has changed the way I work forever. Git allows you to commit early and commit often, safe in the knowledge you can always reorder, combine, remove and/or re-comment your changes later.
This frees you to experiment without worrying about losing the progress you've already made. If you reach a dead-end, it's easy to go back and start working in another direction, while saving the branch in case you change your mind.
Basically, once you get past the learning curve, git makes it extremely easy to remain in that most blessed of version control state of having no uncommitted local changes. And once you've saved with with a commit, it's pretty hard to permanently lose it.
at least, before you push changes to another repo, if you're doing that.
Considering that there are multiple widely used code review systems based on git that aren't based on pull requests, I can safely say your premise is null and void. Not to mention I can't quite parse the broken grammar of your second sentence.
> my company decided to move just to use pull requests as a poor man's code review tool
Using Git, and using pull requests as code reviews are two very separates things. Many people addressed the first point (e.g. Why git is totally fine), so I'll focus on the second one: code reviews with Git. Pull requests is one of many ways to do it, which I personally find difficult with bigger teams working on non open-source projects. I'd recommend looking at Phabricator as a code review tool that works really well in teams.
sadly, my company decided to move just to use pull requests as a poor man's code review tool. sigh. I'm the 99%