[forwhomst]

Why do you dislike perforce? I’ve used them all and git is the worst, in my opinion, of the ones that aren’t dead and buried (like cvs). Perforce is my fave.

Internal research at google suggested that ‘git5’ users were objectively less productive than average, but there’s some friction around ‘git5’ so that doesn’t necessarily implicate git itself.

[rak00n]

You have to be bluffing. I never heard of such internal research. How is even productivity measured in a context like this?

[joshuamorton]

Google has an entire engineering productivity research team. They do research on tooling and such all the time.

[rak00n]

I wasn’t doubting on existence of a research team like that. I was doubting on the research mentioned. You cannot just say people who use a particular tool (like git or git5) are less productive. That’s just absurd.

[joshuamorton]

I don't think the research is public, because it's all entirely about internal tools, but yes the conclusion was that the got interface for perforce led to less efficient development across basically any metric you could look at (LoC, commit count, self-reported efficacy, etc.). Note that if you judge developers based on commit count is a bad metric, but comparing LoC throughout of developers who are evaluated on other metrics isn't problematic.

[rak00n]

I just searched in moma with variations of “git5 productivity” and no such study showed up. Neither LoC nor commit count is a good metric to represent a developer’s productivity.

In my personal opinion, using a git/hg like interface makes it lot easier to work on a complicated CL because you can maintain internal local branches and you can easily revert your incremental changes. That’s not at all possible in perforce. I just can’t see how git/hg interface can make anyone less productive.

[joshuamorton]

> Neither LoC nor commit count is a good metric to represent a developer’s productivity.

They're not a good metric to judge a developer on. But when you can do a large controlled study (or even before/after with the same developer), without the developer knowing they're being watched, it's a good metric.

[jayd16]

I mostly dislike the general bugginess, the need to use plugins of varying quality in all your tools, the centralized design and/or poor dvcs support, and the strange feature dead zones you get. As far as I can tell (and I opened a ticket but maybe I pulled a bad support tech) it's impossible to see what CLs were merged into a branch, only what still needs to be merged.

The general low quality of a lot of the Perforce tools has me scratching my head every day. How hard is it to make a log window that scrolls to the bottom? The p4proxy doesn't have a max size, you need to manually delete files on the machine to free space!?

[forwhomst]

You can definitely inspect the changes that have been integrated into a perforce branch with filelog and changes, it's not worth pointing out exactly how, you can find examples online (much like git). And if you don't like how p4proxy behaves when it runs out of space, just wait until you experience git with a full disk.

[jayd16]

Git works better. You can prune git or delete lfs files remotely. P4 proxy stores every file revision it touches and does no book keeping. Revision count is not honored and obliterate doesn't clean it up. P4 proxy will grow unbounded and take up much more space than your master repo. The only way to clean it up is manually deleting raw files.

As for a single command to see already merged/copied CLs between two streams, please enlighten me. I want the unsquashed CLs. It would be really useful for generating patch notes but because p4 does version tracking at the file level and you can merge some files from a commit and not others etc, it's not trivial at all.