Linus is snug as a bug in a rug, having solved his own problem of dealing with e-mailed patches. This also works for many coders with similar work-flows.
But, for work-flows with binaries (documents, images, executables, etc.) Perforce looks better, if you read through the comments in the LWN piece. For instance:
[git, problems with binaries] this has been documented several times, but it seems to be in the category of 'interesting problem, we should do something about that someday, but not a priority' right now
The article above talks about Google's work on the Linux kernel, something that is managed competently with Git outside of the company.
Granted, Linus's comment is a sweeping statement (as most snarky comments tend to be) but in this context, Perforce seems woefully inadequate for managing Google's kernel work.
Comments
Take that with a grain of salt.
Linus is snug as a bug in a rug, having solved his own problem of dealing with e-mailed patches. This also works for many coders with similar work-flows.
But, for work-flows with binaries (documents, images, executables, etc.) Perforce looks better, if you read through the comments in the LWN piece. For instance:
[git, problems with binaries] this has been documented several times, but it seems to be in the category of 'interesting problem, we should do something about that someday, but not a priority' right now
P.S. a couple of months ago, in another HN discussion, stevelosh kindly contributed a link about the bfiles extension for Mercurial: http://mercurial.selenic.com/wiki/BfilesExtension
The article above talks about Google's work on the Linux kernel, something that is managed competently with Git outside of the company.
Granted, Linus's comment is a sweeping statement (as most snarky comments tend to be) but in this context, Perforce seems woefully inadequate for managing Google's kernel work.