Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks.
> SVN embraces a workflow that is inferior.
It is different but what exactly makes it inferior?
I was in exactly this situation at my last job (minus the same room, I was stuck in a separate office). In spite of the main source repo being SVN, we all used git-svn as our client.
The main benefit is that git makes it easier to create clean commits and push them to trunk.
E.g., I want to make module Foo, and use it in Bar. I can use git as I go, building module Foo incrementally over 5 commits (none of which has sufficient quality to go into trunk). Then I can do 5 more commits which integrate Foo into Bar. So my individual history is tracked while I'm developing. If, while building Bar, I make a bugfix to foo, I can commit it.
So logically, my commits look like:
101-104 Work on Foo
105-107 Work on Bar 108 Bug fix on Foo 109-111 Finish work on Bar
When it comes time to push to trunk, I can rebase 101-104 + 108 into one clean patch, "Built module foo", and 105-107 + 109-111 into "Incorporate module foo into bar". Then I eventually push these into the main repo.
Further, if I'm working on this with someone else, we can use git to track work between the two of us without committing to mainline.
Also, part of the point of the workflow is to make sure all commits to the official repo are clean code. Using a feature branch means that the official repo contains commits like "Halfassed implementation of foo, joe take a look at it".
Because with svn you end up having dirty working directories that go uncommitted for days because committing would break the build, as a result:
1. Everyone ends up making a second working directory because the first one they have is dirty with changes they can't yet commit and they need to make a quick change
2. Those dirty working directories are branches in practice, even if svn doesn't call them that, they are just dealt with with inferior tools.
Also: cherry picking commits from a branch into another branch isn't as easy, making a new repository isn't as easy, git is way faster at (almost?) everything (including large binary files), and being able to check the history when you are not in the office or connected to the VPN is nice.
However, I agree that the conceptual model behind DVCS is harder to understand, significantly harder, svn can be good enough especially for a small, local team.
I don't think I have said it doesn't
The thing is, when you solve the problem of dirty local workspaces by making them actual branches svn becomes just as complex as git, probably even more so given that all the branches exist for all the users. And you still don't have has good interface for cherry-picking, you still need multiple local copies, it still isn't as fast and you still don't have all the other benefits associated with a DVCS.
Cherry-picking and speed are legitimate benefits of git.
But those branches would be a solution to the "I cannot commit this yet" problem. And at least on the repository side it is a cheap FSFS copy.
However, I don't want to make them branch because it would pose the same issues unfortunately...
You describe my environment almost exactly. I am pushing for a git migration mostly for the low-overhead branching/merging as I can have multiple discrete tasks on a given project which need to be rolled out individually.