initialcommit

Thank you! So glad it's been useful :D

Lol... fully aware it's a kooky project, but I've had a lot of fun working on it.

either way glad you got a laugh ;)

It can basically do all this: https://www.youtube.com/watch?v=BF7FnK1Gml8

Questionable decision on my part! :D

Yeah! This is a great tool and it's been around for a while. Nice little puzzles and good to have some kind of visual representation. But Devlands can do so much more than visualize the commit graph: https://www.youtube.com/watch?v=BF7FnK1Gml8

Kinda! But really only in the sense that they're both "games" related to Git.

Devlands can do so much more (it's can simulate, run, and visualize any command or scenario that can happen in Git within the context of any local repo) and in a much more intuitive way.

Haha yes I am extremely curious to hear the answers to these questions as well to understand the utter stagnation here.

Hey there! Never heard of Luanti, but the reasons I chose to make this in Pygame using this particular open-source voxel engine implementation are outlined in the post :D

Thanks! Yeah I've seen that before. Nice that it's online and nice little puzzles but pretty limited in what it can do by comparison.

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.

Yes totally agree. Curious if you think visual or gamified tools might have been useful to get an initial grasp on the types of concepts you mentioned? And if so where they might fit in?

Hard agree. I love this mindset! If you put a tool in your toolbag you should know how to use it.

Git is definitely abstract and hard to get the hang of but totally worth it - pays dividends in terms of the options it puts at your disposal. And the stimulating nature of learning how it works so that you can think for yourself to figure out a solution, instead of just memorizing 3 commands and running to AI for help when you get a little stuck.

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

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.

But glad you got it working too!

You can use the --reverse flag to reverse the direction of the graphs in Git-Sim.

However the fact that time flows in the opposite direction of the parent/child relationships, is inevitable based on Git's design.

Ew clone a repo to simulate a command?!

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.

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.

Will need to think about it more...

Nice I need to find some time to actually sit down with Mercurial for a nice summer afternoon

Manim rocks.

Yes much agree!

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.

Good suggestion, I will add that.

Sweet! Yeah the slow animation is a Manim performance limitation, I think (hope) their community is working on improving that.

Yes --low-quality works for testing but the fastest way would be to first test without the --animate flag at all, so you just get a final image of the command's effect.

Then once you get that you can add the --animate flag to generate your final video to share.

And awesome to hear it will be used for your company session! I love teaching people about Git. Feel free to share the tool with them so they can try it out as well!

Thanks for checking it out!

Would be great to get any feedback you might have if you get the chance to install/test it out.

Interesting thought - do you mean like a line of text that displayed above that verbally described what's happening?

I was considering adding some more detailed text-based output on the command-line detailing what was going on, but I didn't think about adding it directly into the image/video.

Hey there fellow Mac user! And thanks for testing it out - were you able to get it installed or is it still chugging along?

Yes I feel your pain with Homebrew which can take forever just to check for updates on installed packages, before it even gets to installing anything new.

I know the current installation method of having to first install Manim's dependencies is not ideal, but in most of my testing it was relatively painless.

However going forward I am going to be looking for ways to make it a single install instead of various steps that differ across platforms.

Haha wow you posted this before I could! I created Git-Sim and hope that folks can get some use and value out of it. Happy to answer any questions anyone might have, and especially looking for feedback so that I can improve the tool. Also if anyone is interested in contributing let me know and also check out the project Github page:

https://github.com/initialcommit-com/git-sim

Most devs overlook an excellent resource for improving their coding and dev skills - learning from early versions of open source codebases.

Reading other peoples' code and understanding it can be incredibly useful in various contexts.

In the spirit of this, I tried my hand at understanding how Git's code works. It turns out that Git's original version - i.e. Git's initial commit - is written in the C programming language and consists ONLY of ~1,000 lines of code.

I found it so interesting and learned so much - and want to encourage other devs to do the same.

Jumping into a new codebase can be intimidating, so I put together a guidebook to help devs learn how Git's original code actually works - the Decoding Git Guidebook for Developers.