Re: Request to remove Junio C Hamano as the Git Maintainer

I apologize for reopening a conversation that probably has already gone on too long already (I won't particularly comment on the misguided attempt this thread was initially started for), but I actually have some limited data points about perception of Git that could interest people.

I'm on the project at Salesforce to move our thousand+ of developers on our 1-million-file monolith, from ~20 years of using Perforce, to using Git. Obviously it's a legitimately painful move for some, so when the project got funded as a top priority, there was a decent amount of concerns expressed by people about Git's reputation of being complicated to use. We noted it as an adoption risk of the project, and we were sufficiently funded to drill into understanding that risk for our user base, so we did.

For additional context, our user base is made of very diverse technical comfort levels. We have interns whose knowledge of Git is one chapter of one class they had last year; we have people who have been working with Git at Salesforce on smaller projects for years; we have people who joined recently and have been working with Git outside of Salesforce for years; and we have people who have been working on the monolith at Salesforce for 20 years and never had to get into Git.

Here are some interesting data points:
- Our beta went live in November, and we now have 600+ users who
onboarded. The perforce route is still being supported for now, and
there is no incentive to switch, so it's all organic adoption.
- We do most of our support on an internal StackOverflow instance, and
move the conversation to Slack when the conversation needs to be more
synchronous. We braced for having to support people through struggling
with Git situations, but that never really happened. We currently have
200+ StackOverflow questions from people using our product; but only
~5 of them are about struggles with Git itself. All others are about
the infrastructure and tooling we built around it to mitigate our
scale, or issues using our app's build tools, that people mistakenly
thought were related to Git because they happened to have recently
switched, but were not. The wave of supporting people out of Git
struggles hasn't meaningfully happened so far.
- We sat down with the customers with the loudest concerns to build
understanding, and so far my read is:
  a- A lot of concerns we've heard that can be legitimately attributed
to something that has usability downsides with Git related to
Perforce, also offer compelling upsides that seem to make them worth
the downside so far. For instance, Perforce versions per file so
people could "get latest version" on any file separately without
impacting their other files and their "status"; but when we explain
people the upsides of Git versioning the entire codebase at once,
particularly how the top root cause of local build errors have been
due to the perforce sync having silently failed on some files, which
can't happen with Git's approach, this kind of usability downside gets
really easy to justify.
  b- Most users we've heard strong concerns from are people with a lot
of seniority on core at Salesforce. A lot of their concern seems to
boil down to the legitimate loss of value of the perforce expertise
they've built over the years. It is a very legitimate concern, but
it's a concern we have chosen to disregard because we feel it ties too
strongly with reasons companies sometimes don't adapt, and the dangers
that come with it. In fact, the fact that the concerns are limited to
this kind of user profile tracks well with our initial feeling that
this move to Git would allow us to better include newcomers and
leverage industry-wide skills.

Obviously this is somewhat anecdotal, our user base is basing comparative judgement on one alternative only (perforce), they have other common needs related to the app itself being managed, and we haven't yet issued a mandate for people to switch so a lot of concerned people are probably hiding a bit until then. So, I'm not sure how representative of the broader Git user base ours is. But if one would consider that it is reasonably representative, then it would fairly strongly disprove the notion that people have legitimate systemic problems with Git itself.

Still, I hope those data points are interesting to some. They definitely have been fascinating and surprising to me!