[klodolph]

> Git is the best source control system ever.

To be clear, I'm not disagreeing. But it is simply not good enough. Any new generation of source control needs to be able to do things that are difficult with Git, and Git simply isn't extensible enough. Microsoft has a Git VFS, and there's Git LFS, but this just doesn't go far enough.

There are good technical reasons why you would use Perforce or even Subversion these days.

The people who made Git made it for working on large, but not huge, open-source code repositories with a traditional model. It doesn't work so well for vendoring, it doesn't work well for artists, it doesn't have locking, it doesn't have access controls (and there's only so much you can add). You can argue that these features don't make sense or we're using Git "wrong" or I can write a bunch of hooks but at some point I just want them to work and I'm tired of fighting with Git to make it happen.

Just personal background, these days I work with closed source and open source, monorepos and multirepos, Git, Subversion, and Perforce all on a regular basis (and sometimes use weird custom setups). Git is by far the most familiar of the three, and I've published some tools for Git repo surgery.

[hashkb]

> There are good technical reasons why you would use Perforce or even Subversion days.

Can you say more? What are some of those reasons? Or link to some data or examples?

[Tempest1981]

With a monorepo, how do you avoid the situation where almost every time you want to commit, you have to pull-and-rebase first? Because somebody has always pushed a change, every minute or two.

[majewsky]

In a repo that large, you don't want to have random people pushing to master anyway. Have people commit to branches, and then automation merges the approved branches into master. ("Automation" may be as simple as the "Merge" button in Github's UI, or more complex if necessary.)

[Tempest1981]

With git, can you set specific user permissions by directory? We need a way to prevent pull or commit by certain users.

Or require a review before committing to some projects/dirs, but not all.

[tempguy9999]

Simplicity. I understood SVN immediately but I'm still struggling with Git.

It's only one thing and perhaps the only one, but it's a huge one. IMO anyway.

[emcq]

Partial checkouts is the main thing that comes to mind that is better with svn than git.

[falsedan]

git archive is ... ok, not pretty great, but it works

[klodolph]

That's not really a working copy, though. What some need is a tool that lets you check out a part of the repository as a working copy, without checking out the rest. By "part" we might mean more than one directory and its descendants (i.e. not a single root).

[falsedan]

hmm, you could frankenstein together a bunch of trees to make it look like a partial checkout, but you couldn't make a new commit without all the parent tree objects up to the root. This sounds just like a subtree to be honest.

Are you frequently checking out a subdir of a repo and committing changes to it? Is it config?

[klodolph]

The particular case I'm thinking of involves a repository which is large enough that full checkouts are slow, so you do partial checkouts to make things faster.

Maybe at some point there will be tools that let you do this with Git, maybe built on top of something like Git VFS. At the moment it just kind of sucks. Subversion and Perforce both handle it just fine.

[falsedan]

> it doesn't have access controls (and there's only so much you can add)

so there's a lot of drawbacks to using gitolite but we were able to customise access controls down to allowing some users the ability to only change lines of checked-in config only to certain values

[klodolph]

How do you prevent users from reading certain parts of the repository, though? This was what I meant by "there's only so much you can add"... you can reject pushes that change parts of the repo, but you can't prevent reads without breaking everything.

[falsedan]

> can't prevent reads without breaking everything

I don't understand, you can lie to git-upload-pack and send anything you want to the user?

but when we used gitolite, we put sensitive stuff in a separate server and restricted reads to trusted users/deployment tools

edit oh I see, you want to let some people clone the repo but with some stuff redacted and still be able to make changes to the non-redacted stuff. I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement

[klodolph]

> I'd used LFS and move the ACLs to the file server, if using a single repo was a hard requirement

If you're putting a few large files in LFS, or maybe a couple sensitive files, I can understand and I'd say you're still using Git, but with some extensions.

If you're putting an entire sensitive subtree in LFS, I don't think you're really using Git any more, in the sense that many of your standard Git workflows will have to be different.

[kadendogthing]

You have completely missed the point of my post. The point was my post had as much substantial points as the article in question, with less words obviously. Which should be obvious but never get in the way of a good tech contrarian article stating everything sucks I suppose.

[klodolph]

Ah, thank you for the clarification, I had interpreted your comment far too generously.

[jessemillar]

Out of genuine curiosity, do you know of any resources you could point me to to explore specific situations where Git isn't fitting the bill technologically?

[klodolph]

The big one is anything that requires locking. Git by nature doesn't support locking.

The next one is repository size. Anything with extremely large history size or checkout size. Very hard to work with using Git. Microsoft has Git VFS. Facebook and Google have modified versions of Mercurial and Git.

High repository velocity. If you are trying to push to a remote and you are always out of sync, it's going to slow you down.

Checking out different commits for different parts of the tree. This one is a bit more rare, it's less common that you'd want this.

Finally, setting ACLs to deny read access to parts of the tree.

For all of these cases, there are some ways you can work around the problem. It's not like you're completely dead in the water with Git, it's not like these things are completely impossible to do in Git. It's just that Git isn't good at everything. It's just that Git is exceptionally good for most people who write code.