That's such a relatable story - and I feel like it highlights something I've been thinking about a lot while working on these visual and gamified Git tools.
There's this whole class of capable engineers (some at senior/staff levels!) who just never had to build good Git habits or learn how to think about the different options that Git's command set provides, because their workflow didn't demand it.
Curious - do you think that's mostly a tooling/culture thing, or more of a learning gap, where they just never had a reason to dive deeper?
Part of why I'm making these tools is to explore if a more visual approach might make some of those concepts stick better. But curious what you've seen actually work in practice for helping people improve their Git skills.
haha this is a bit of a sad take in my opinion, because of the value that I feel that comes with understanding how a tool like Git works behind the scenes, but seems to be several folks here who feel the same way you do
I feel the same way. All of git's weirdness seems totally reasonable once you understand it on its own terms. It doesn't even take a ton of understanding to get that that point either.
It's not a sad take. There are many roles in tech and I'd encourage those trying to make things to focus on that. You can get extremely far with 4 git commands. Even in a production team environment, you may only need to ever add in the merge workflow.
I agree with you. My typical workflow is: update master branch in Visual Studio, create a new branch off of the master, work on it, when ready use GitGUI to commit and push, then do a merge request in GitLab (we use GitLab). When approved, I push the branch to master. From time to time I need to update my branch, either because I make some code changes, or because my branch a few commits behind the master.
Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
The reason it's sad to me is because there is so much more to explore, to be stimulated by, to be able to apply in a way that makes you think out of the box.
Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
Thanks for sharing your workflow - nice and simple! And sounds like you've got a rhythm down with those core commands, which I know is the case for many Git users.
One of the things I'm trying to explore with these visual and gamified tools is how to help newer Git folks or even users who mostly live in that commit/push/pull flow get a clearer mental model of what's actually happening under the hood.
Git has a really wide breadth of functionality that is kind of interesting on its own merit, but also useful for a plethora of different tasks. For better or worse even Git experts can always find ways to expand their knowledge :)
Ah good! Glad to hear it. I had some issues when trying to install it on Mac's using the system Python. Switching to a homebrew-installed version of Python >3.7 worked for me in my testing.
Hehe jk you make a fair point, and in fact I do have a bunch of work left to do to make sure my simulations do match up with Git's behavior as closely as possible.
One big benefit I was going for with Git-Sim though is to interrupt the developer workflow as little as possible.
Changing directories, running a new clone (which could take a mildly annoying amount of time), and running gitk is a pretty big context-switch.
A big reason I wanted to pursue this idea is exactly what you mentioned - a lack of ability to easily create presentation-quality Git structures that can apply specifically to the situation a user is in, NOW.
A super annoying thing about troubleshooting Git issues is when you find a similar solution online but it's done in someone's random repo which could be very different that yours. Your whiteboard sessions are another good example down this line of thought.
This is a great point. I thought about how I could simulate commands like "git pull" and "git push", but like you said that would require communicating with the remote to determine ... stuff ... like what objects need to be synched, and potentially even doing some of the actual data transfer before an accurate simulation would be possible.
My initial goals for this tool are to purely simulate actions on Git repos without actually modifying them, but I might be flexible on that going forward, as I mention in the article with the --execute flag.
> simulate actions on Git repos without actually modifying them
One way around this could be to create a new temporary directory in /tmp, copy .git over there and symlink the rest, then run whatever operation in the newly copied workspace and compare it with the original.
Then you can mutate things however you want and the original stays the same.
Hey cool idea! I'll definitely consider that and variations on it. This could work for Pull-direction operations like fetch/pull, but maybe not as well for push since the remote would still be affected in some way.
Was gonna suggest the same! I use this countless of times. It's really cool how you can push/pull to a bunch of different things, including directories, ssh hosts, anything that can act as a directory (network mounted FUSE directories) and more.
Personally I use it a lot for backing up git repositories to a USB stick where I have a backup of every single repository + its branches and commits in case I ever need to recover from them. And I can keep my GitHub remotes clean without 100s of branches.
There's this whole class of capable engineers (some at senior/staff levels!) who just never had to build good Git habits or learn how to think about the different options that Git's command set provides, because their workflow didn't demand it.
Curious - do you think that's mostly a tooling/culture thing, or more of a learning gap, where they just never had a reason to dive deeper?
Part of why I'm making these tools is to explore if a more visual approach might make some of those concepts stick better. But curious what you've seen actually work in practice for helping people improve their Git skills.