HN Explorer

Ask HN: How to ease in Git to someone with Git PTSD

9 points by lastdong ↗ HN
I came across some colleagues who can’t stand Git (even the slightest whisper).

Alternatively, Perforce is used extensively in the gaming industry, really good integration with Unreal Engine.

Yesterday, I finally understood why: in their previous team, someone who didn’t understand Git at all, brought it in, and they ended up commiting directly to master and using spreadsheets to track who was editing what (no gitflow, no PRs) - just baffling, of course it didn’t went well, and of course they hate it.

How do I get them to trust the Git system again is an interesting challenge, but Perforce works, and basically wanted to share this amazing story.

19 comments

[ 3.0 ms ] story [ 59.8 ms ] thread
MrWiffles
Have you shown them all the interesting and useful features that comprise the git ecosystem yet? Things like GitHub, maybe with its releases, wiki, issues, discussions, etc., perhaps GitLab with its ops/CI/CD features, etc.? That may be juuuuust enough to get them to overcome their "yuck" factor for just long enough to give it a real chance.
lastdong
Thanks, well summed up! I’ll definitely go through all of those, baby steps I guess
gumby
Is your team in gaming? If so they will want to stick to Perforce because it handles binary files and otherwise large assets well, while git realistically only supports text files and does deltas by line of text.

I truly detest Perforce with a passion but I understand this use case.

lastdong
Yes, that’s pretty much the case! Same here, Perforce has advantages for binaries, but there is some internal tooling, Python based, which will benefit from Git.
gumby
Would it benefit from not being in the same system as everything else?
lastdong
Apologies, missed your comment… Basically the overhead of creating and managing repos on gitlab is currently less complex, organizational speaking. but it is a fair question and maybe processes need to be improved to enable other scenarios.
lifthrasiir
> [...] there is some internal tooling, Python based, which will benefit from Git.

Do not speculate; quantify it. The switch to Git will affect the whole team, your proposal should be as complete as possible.

My last workplace---also in the gaming industry---once used a mix of Git and Perforce, but now exclusively uses Git. This was not a light decision, artists and client programmers preferred Perforce for a good reason and using both Git and Perforce did work albeit with caveats (we had lots of tooling to synchronize both repos for example). But engine and server programmers also did have a good reason to use Git, especially because they did a full code review and relied on fast branching. So we developed a simple graphical interface to Git LFS for artists and client programmers, which finally made the switch viable. If we didn't have such interface and forced Git for everyone it wouldn't have worked at all. (To be fair, some still complain and it is an ongoing challenge to maintain the interface though. My very last job in that company was working around a bug in Gitlab's handling of Git LFS.)

gumby
> So we developed a simple graphical interface to Git LFS for artists and client programmers, which finally made the switch viable...To be fair, some still complain and it is an ongoing challenge to maintain the interface though.

Wow. My experience is that it wasn't worth the hassle of trying to make this change. Actually the other way (standardizing on Perforce) would have been a major hassle too.

At a prior job where we confronted this we had Perforce (game and some other host code), git (various low level stuff like kernel) and whatever the cad guys used. And google docs which of course have a painful and vestigial versioning system. In that case we had bigger fish to fry than the data control systems.

lifthrasiir
How did you synchronize all the things? I think it'd be the single biggest factor; if you don't have to synchronize them frequently, or you have a brilliant way to synchronize them without relying on repos, multiple repos can indeed coexist. In my case however this resulted in lots of problems even when we had out-of-band tooling.
gumby
It was a nightmare; the only saving grace was that team was small enough that everybody could talk to everybody else.

We might have been able to eliminate Perforce (though there was one particularly cantakerous game dev) but then we'd still have the CAD data issues, so I threw in the towel on this problem.

Oh, I should be clear: I didn't mean "synchronize" in that code went back and forth between control systems, if that's what you meant. Device code (kernel, drivers, etc) was in git and stayed there; game code and assets were in Perforce and stayed there; and CAD stuff was in whatever that system was. And we never had good document control as we used (ugh) google docs and text files in the various repos.

tobbob
Start using it yourself, raise some PRs, get them to review it, bring up diffs on the screen, just ease them into it a bit. If you're confident using it, that might help them learn to trust it again.
gorjusborg
Have you asked yourself why you want to introduce git if team has an alternative they prefer?

The answer to that question gives you what you need, bit could allow you consider whether the trade is worth it.

I have convinced gitophobes in the past, but the team was mostly on board, it was the minority that needed coaxing. That is much easier, because you can suggest trying it by working with those open to it. Generally people will cave to FOMO as others are learning together.

I would also keep in mind that there is a upper limit to how much 'selling' you can do to someone, so make sure this fight is worth it before using up the political capital needed to get them there.

JimmyHoke
Maybe try having them use a nice GUI tool like Sourceforge. That way they won't have to learn any commands, and everything will be in a clean graphical format.
tscopp
Large binary assets don't scale in git, even with LFS and similar solutions. At that point the pain of having code in multiple places far outweighs the pain of being on a really annoying platform like perforce. As you mentioned you'll also miss out on a lot of tooling (in perforce and unreal) and trying to replicate that functionality with git on the backend (struggling with large binary assets) will bury the project.

If you're making a game perforce is the only legitimate option. Unless you hate your developers, then try alienbrain.

lifthrasiir
If your workplace doesn't naturally need branches, like, PRs are to be merged immediately, then it is very hard to convince your colleagues. In fact I don't think you should in that case, your team's workflow wouldn't be a good fit for Git anyway. Using spreadsheets does sound problematic, that's why locking exists in Perforce and many other centralized VCSes, but that can be fixed without introducing Git.
bulatb
Git is software for manipulating graphs which, instead of drawing a graph you manipulate, makes you memorize a bunch of strings of magic words that map to certain transformations given certain graphs, try to imagine the current state of the graph, try to figure out which magic words will change the state you think it's in to a different state you want, try to imagine that state, then apply the transformation without seeing the result, and then type other magic words to try to figure out if typing words transformed your graph the way you thought.

Instead of showing you a graph and letting you change it.

It's mainly used by people who would say they're writing software, not manipulating graphs.

It also doesn't tell you this is happening, so people coming from another VCS don't even know there's this whole other part they should know. They memorize commands that seem to work, it goes ok, and then one day they ruin everything. Silly, that command means something different in the context you had no idea you were in. Duh.

Their experience with Git is that it's hard to make it work and then it randomly blows up. It's not because they're stupid or lazy. They're normal people dealing with a system that from their perspective is almost cartoonishly hostile.

They might wonder why they need to care about some underlying data model just to save their work instead of what they're doing now. If you have an answer that will make them want to switch, I suggest you spend a good while showing them pictures of history trees and ways you can change them. Name things slowly: this node is a "commit," this state change is a "reset," this transformation is a "rebase." If you have a workflow on top, draw more pictures of its states and changes using those terms. Then (re)introduce Git, a tool that does what you've shown them. Then set them up with a client where they have that flow with those terms and a graph they can look at, if not manipulate directly.

lastdong
Thank you for all your answers! You made very good points.

To answer some of the questions:

- Perforce isn’t going way, Git would just there for projects that will benefit from it (generic tools, less overhead setting up a repo)

- Git will need to bring value for the people using it (it’s just a tool), so something to think about

- Git graphical ui is definitely a good idea, I think it will also show better what operations are available for different contexts

- Definitely taking into account understanding Git graph and snapshot concepts is a very good start, as well having graphical visualisations