3 ms·

I don't think he was that negative. It's a well know issue the problem that git has with large files, and he was not disrespectful.

deathanatos 12y ago
> It's a well know issue the problem that git has with large files, True to some extent. (Large files I will agree with.) That wasn't his only argument: the other was about large repos. I've seen many places try to attempt a 1:1 conversion of a Perforce depot to a git repository, and this will likely not work well: the Perforce depots are simply too large. A Perforce depot typically, in my experience, contains the entire source code for the entire company. A Git repository would be suitable for a subtree in that depot that represents a logical project, often managed by a team of related co-workers. So one Perforce depot would correspond to multiple git repos; however, like I said, I feel like people try to shoehorn the entire depot into a single repo. The downside is you have multiple repos, whereas before you had a single large repo, and any cross git-repo changes would be made in a single changelist. In git, you'll need multiple commits, and some way to manage inter-repo dependencies in those changes. (Such as semantic versioning, and a decent build system.) The downside of Perforce that I ran into while working with it is that it lacks git's branching model, many of git's day-to-day conveniences (I so miss git add -p, git commit for just pushing out small fixes that either don't need review or for which review is trivial), and frankly, the fact that a commit hash represents a set state. (Between creation of a changelist, running tests, and submitting the changelist, someone can break you; this is not possible in git, as the push will fail.) In the long run, I greatly prefer the extra management work of git for the power it brings with its branching model. > I don't think he was that negative. > > Most grownup software shops use Perforce In my reading of this, there is an insinuation that shops using git are not "grownup"; I would call this disrespectful, myself.

deathanatos 12y ago

> It's a well know issue the problem that git has with large files, True to some extent. (Large files I will agree with.) That wasn't his only argument: the other was about large repos. I've seen many places try to attempt a 1:1 conversion of a Perforce depot to a git repository, and this will likely not work well: the Perforce depots are simply too large. A Perforce depot typically, in my experience, contains the entire source code for the entire company. A Git repository would be suitable for a subtree in that depot that represents a logical project, often managed by a team of related co-workers. So one Perforce depot would correspond to multiple git repos; however, like I said, I feel like people try to shoehorn the entire depot into a single repo. The downside is you have multiple repos, whereas before you had a single large repo, and any cross git-repo changes would be made in a single changelist. In git, you'll need multiple commits, and some way to manage inter-repo dependencies in those changes. (Such as semantic versioning, and a decent build system.) The downside of Perforce that I ran into while working with it is that it lacks git's branching model, many of git's day-to-day conveniences (I so miss git add -p, git commit for just pushing out small fixes that either don't need review or for which review is trivial), and frankly, the fact that a commit hash represents a set state. (Between creation of a changelist, running tests, and submitting the changelist, someone can break you; this is not possible in git, as the push will fail.) In the long run, I greatly prefer the extra management work of git for the power it brings with its branching model. > I don't think he was that negative. > > Most grownup software shops use Perforce In my reading of this, there is an insinuation that shops using git are not "grownup"; I would call this disrespectful, myself.