[findjashua]

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!

[gcb4]

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.

[findjashua]

>>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.

[recursive]

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.

[smt88]

Before git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git.

Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.

[pimlottc]

> Before git-based package managers became the norm

When did using git-based package managers become the norm?

> it wasn't uncommon to track/update dependencies manually using command-line git.

Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts?

(I'm guessing you're speaking from a JS dev perspective?)

[smt88]

> 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.

[recursive]

I wasn't aware that git-based package managers were the norm, but I've used third party libraries in two different ways.

1. Nuget packages inside Visual Studio 2. Download the library using a web browser, and just put it where it needs to be.

I'm sure some people would scoff at this list, but it does demonstrate that you can certainly use third party libraries without using git.

[smt88]

> 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.

[findjashua]

If you want to look at the commit history or submit a patch, you'll need some sort of version control.

[recursive]

That is by far a minority of my uses of third party libraries.