22 ms·

I struggled with Git, so I'm making a game to spare others the pain

246 points by initialcommit 2y ago

pestatije 2y ago
everybody does...instead of playing games lets put the worshiping to one side and start using alternatives
- mopsi 2y ago
  What alternatives do you recommend?
  - zabzonk 2y ago
    mercurial was arguably better - but switching to it is probably a bit silly now
    - mdaniel 2y ago
      I haven't tried it in a while, but mercurial supports reading and writing to git repos: https://wiki.mercurial-scm.org/HgGit https://wiki.mercurial-scm.org/HgGit and its page says that https://wiki.mercurial-scm.org/GitExtension https://wiki.mercurial-scm.org/GitExtension is bundled, but doesn't handle all of git's features
    - convolvatron 2y ago
      why? I had to stop using it because no one else would, and the various centralized services dropped support for it. but it handled branching and merging much better, was easier to pick up, and was less likely to trash your local checkout. maybe if someone rewrote it in rust it would be sexy again? rurcurial?
      - DrinkyBird 2y ago
        You jest, but… https://mercurial-scm.org/help/topics/rust#rhg https://mercurial-scm.org/help/topics/rust#rhg
      - BeetleB 2y ago
        > maybe if someone rewrote it in rust it would be sexy again? They have and it's called jujutsu :-) https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj OK, it's not a Mercurial clone, but it did take some features from it, and using it will feel more like Mercurial than git. And you can use it on git repositories, so you can have your cake and eat it too.
      - zabzonk 2y ago
        I think the loss of the google and bitbucket repositories was the main problem - i know that took the heart out of me for doing foss development. i can deal with git (shit, i can deal with rcs), but i don't like it.
    - DrinkyBird 2y ago
      Modern Mercurial with evolution is extremely pleasant, and the more I use it the more I abhor git whenever I have to go back to it. That plus Heptapod (fork of GitLab with Mercurial support) — it’s very nice indeed. I count myself lucky to mainly contribute to a project where we use all of this. It’s a shame there’s still nothing quite like GitHub for Mercurial (anymore), where anyone can just sign up and create repositories. Heptapod has a public instance for FOSS, but it requires approval to create projects. There’s also a separate hosted instance for basically anything, but it’s commercial and costs money. One can also self-host, but GitLab is not exactly lightweight, and other solutions aren’t as integrated with evolution features.
  - forks 2y ago
    jujutsu: https://jj-vcs.github.io/jj/latest/ https://jj-vcs.github.io/jj/latest/
  - lylejantzi3rd 2y ago
    ark: https://ark-vcs.com/ https://ark-vcs.com/
  - wetpaws 2y ago
    [dead]
  - Hikikomori 2y ago
    Gitbutler is great.
- 01HNNWZ0MV43FF 2y ago
  I'll be a late adopter, go ahead without me :)
- Etheryte 2y ago
  Git is not good, but I'm yet to see anything that's a clear improvement without sacrificing on the core capabilities. Do you have any recommendations that you like?
  - deleted 2y ago
    [deleted]
  - Novosell 2y ago
    A lot of people love jujutsu/jj.
- fHr 2y ago
  it is already pretty good and far better than svn, mercurial
- starsixtynine 2y ago
  You first. :)
- Nzen 2y ago
  Is there an alternative that keeps the stage(/index) concept ? I acknowedge that the inconsistent argument style looks clumsy when remembering `git log --name-only --oneline`. However, I value the workflow afforded by the stage: I can keep work for several tasks in my workspace until I am ready to commit them. I've checked Fossil, Jujutsu, and Mercurial. Each disavows the stage. I understand that it takes more discipline (and I occasionally fail to adhere to that discipline). But, I'm not interested in the other features of a vcs if it forces me to work on only one thing at a time.
  - WolfeReader 2y ago
    In Mercurial, you are ideally using TortoiseHg. When you make a commit, you can quite easily choose which files or hunks or lines to commit (and which not to commit, obviously). In that sense, the GUI acts as the staging area. For Jujutsu, there's two good options I know of: 1. Use "jj commit -i". This opens up a screen which lets you interactively select files/hunks/lines to commit. You can also pass in a "--tool" commit to use something like Meld. 2. Use the "squash workflow" - basically making your own staging area using jj's flexibility. I can't explain it better than Steve does: https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
    - WolfeReader 2y ago
      Oh, and if you think JJ "forces you to work on one thing at a time" then you have really missed a lot of what JJ offers. Look up "megamerge" - I've done this, and it works well. Here's a link: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...
mjburgess 2y ago
The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic. Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.
- quickslowdown 2y ago
  I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually. I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
  - irrational 2y ago
    If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
    - perching_aix 2y ago
      I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
    - eddd-ddde 2y ago
      No, they said that for a git newbie, a gui will be easier.
    - quickslowdown 2y ago
      I never said if you're not using the CLI then you're a noob. I'm talking about people new to git in general.
  - 2y ago
ctxcode 2y ago
how i've used git every day in the last 10 years: git add -A, git commit -m, git push If there's an error because there are changes on the remote, type: git pull, fix conflicts in case there are any, repeat previous commands In all other cases, google/grok for the solution, doesnt happen often.
- graypegg 2y ago
  Not to be annoying, but maybe one of the most useful things git does for me outside of the usual SCM stuff, is git-bisect. Its saved me many hours of debugging. If you ever run into a case where something is broken (that you can measure, like a test or broken build) but it’s not obvious what change caused the fault, first go to a commit where you know the fault is present. $ git bisect start $ git bisect bad Then go to a commit where you know the fault is NOT present. Go back far if you can! This can be in another branch as long as your start and end spots are connected somehow. $ git checkout abc123 $ git bisect good And after that bisect command, your HEAD will get moved to the mid point between the good and bad commits. Check if the fault is still there, and run either "git bisect good" or "git bisect bad" depending on if it’s resolved or not. It will keep jumping you to the mid point between the nearest bad commit and good commit till you end up at 1 precise commit that caused your fault. This works extremely well for configuration changes specifically, where maybe it doesn’t break in CI, but on your local dev machine it does. You can also use this for non-text files like images to find out when 1 part of an image was changed for example. — Also if you just want to make normal SCM stuff easier, $ git commit -Am "…" For a combo add-everything+commit
  - pigcat 2y ago
    Thanks for explaining this so clearly! I'm going to try this next time :)
- initialcommit 2y ago
  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 :)
bloomingkales 2y ago
The only winning move is not to play. Stick to a few git commands (3-4) and there won't be a whole Alice in Wonderland journey down the rabbit hole.
- initialcommit 2y ago
  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
  - bloomingkales 2y ago
    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.
    - initialcommit 2y ago
      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.
      - deleted 2y ago
        [deleted]
      - deleted 2y ago
        [deleted]
      - nottoohard 2y ago
        [flagged]
    - 2y ago
syntaxing 2y ago
I'm actually surprised how many Software Engineers/Developers don't know how to use Git... I was once showing a Staff SWE on how to setup VScode + Python. I see kinda why when you're programming in vim + C(++) your whole career. But when I told him to push his changes to a temp branch or give me a git diff so I can try his changes myself, he had zero clue what I was talking about. His local `main` was over 2 months old. We had to prune and pull to get it back to match remote. A funner part of the story, I was showing him how to setup VScode because programming using VScode...through RDP. That's right, he was programming remotely on the remote machine using RDP with VScode on the remote screen.
- initialcommit 2y ago
  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.
- graypegg 2y ago
  So on the other side of this, I’ve also seen senior+ folk working on projects alone, with no collaboration at all, but still use a GitHub-esque PR/git-flow process. Almost feels like a professionalism-espousing self-flagellation. Create a PR, self-approve the PR, then merge it to a develop branch. Then merge the develop branch into main. Then in main make a release branch, and tag it.
  - booleandilemma 2y ago
    I'm guilty of this. I open PRs on my personal projects and then merge them in myself. Not for every commit of course, but for the big changes. I just like to see the diffs on the github UI. <shrug>
mlhpdx 2y ago
Oh how I love a good game UX for DevOps.
fHr 2y ago
git is paradise, I now have to use svn, fuck that shit
- bigstrat2003 2y ago
  I'd much rather use SVN than git. I only grudgingly tolerate git because of network effects, otherwise I'd still happily be using SVN.
- _flux 2y ago
  Perhaps git-svn works for you?
- rho4 2y ago
  I have been happily using that shit daily for 20+ years now.
whoateallthepy 2y ago
I learned Git from an O'Reilly book and I loved that it started with the internals first. The git CLI has some rough edges, but once you have concepts of work tree, index, commits and diffs down, it is extremely powerful. magit in Emacs is also incredible.
- nottoohard 2y ago
  [flagged]
- initialcommit 2y ago
  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?
  - fragmede 2y ago
    https://learngitbranching.js.org/ https://learngitbranching.js.org/ is my go-to recommendation
- pxmpxm 2y ago
  Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it. None of the concepts behind git are difficult to grasp, the problem is interface and leaky abstractions all over. Any person that mentions reflogs is actually saying I don't understand any of the points above.
  - skydhash 2y ago
    > Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it. Because learning how a software model a particular problem domain is a great step towards efficient use? You can hope it's magic, but that's a recipe for failure if you're a heavy user. Every professional learns the ins and outs of the tools he uses often.
    - 2y ago
hk1337 2y ago
The main thing I struggle with in git is the habit of “make a change, make a commit”. I will often do multiple commits but they will be all at once as I go through and make a commit and include any relevant changes in the commit.
- rectang 2y ago
  I find that the command "git add -p", which allows you to add individual sections of files rather than whole files before committing, helps with this issue. It's quite natural to wind up with a bunch of work that really needs to be in multiple commits. I don't think this ever changes for most of us.
  - hk1337 2y ago
    That’s basically what I do, I just end up doing it in large spurts. I typically use the cli for most things but I like the GitHub app for picking out changes for a particular commit.
digdugdirk 2y ago
Does anyone use Fossil source control? I've always been interested by it, but it just seems to stay under the radar. I'm curious if there's a functional reason for that, or if github just got to be good enough.
- graypegg 2y ago
  Fossil is the SQLite one right? I would love to try alternatives SCM tools, but you run into the fact that associated tooling is so concentrated on git and its processes. I was using bitbucket and mercurial for a while! If fossil had something similar (which off the top of my head, I think they do? Something wiki-like for the SQLite project) I would be willing to mess around with it on a small team or something.
- QuadrupleA 2y ago
  Been using it for years and absolutely love and highly recommend it. Single executable you just download and put in your path. Sane, well-documented interface. Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. I think it's kind of a tragedy the dev world got so stuck on git. Maybe not too late!
fragmede 2y ago
The problem is I can't forget everything I know about git and approach it with fresh eyes to see if this is good or bad.
cube2222 2y ago
You may also consider using the Jujutsu VCS[0] as effectively a nicer and saner git frontend. I’ve written an intro to it a couple weeks back[1] - I’ve been using it since, and so far haven’t had the need to switch back to git at any point. [0]: https://jj-vcs.github.io/jj/latest/ https://jj-vcs.github.io/jj/latest/ [1]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/ https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...
- CharlieDigital 2y ago
  This one is probably the best intro I've read: https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/ Really, really good examples and walkthroughs with easy to understand, animated console sessions that show real-world-ish use cases including conflict resolution and why JJ's model makes it easier. Really good read and easy to digest because of the animated session replays. My main takeaway is that the missing pieces right now are IDE support for a world filled with detached heads and a foolproof upstream integration pattern on `push` (requires a bit of manual work to designate the target branch).
  - bthallplz 2y ago
    Regarding IDE support, you might be interested in this VS Code extension: https://github.com/keanemind/jjk https://github.com/keanemind/jjk I found it today and like it quite a bit. The Visual JJ extension (https://www.visualjj.com https://www.visualjj.com) is also good, but JjK feels more integrated to me.
    - CharlieDigital 2y ago
      Nice; thanks for sharing this.
- stouset 2y ago
  I am 100% going to link to the original post and these replies next time there’s a jj thread and people express bewilderment about needing anything else because “git is so simple”.
nickandbro 2y ago
Kinda reminds me of https://ohmygit.org/ https://ohmygit.org/
- initialcommit 2y ago
  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.
  - initialcommit 2y ago
    It can basically do all this: https://www.youtube.com/watch?v=BF7FnK1Gml8 https://www.youtube.com/watch?v=BF7FnK1Gml8
CLiED 2y ago
I used to struggle with git until I started to use a GUI, now it just works but I get far less hacker cred therefor, which is regrettable.
- rectang 2y ago
  Heh. I care about results from my colleagues and collaborators, not their tool preferences. If your topic branches and commit messages make sense, that's what matters — because those are our touch points of collaboration.
- metabagel 2y ago
  Which GUI?
  - wingerlang 2y ago
    Not OP, but I've been using SourceTree for over a decade. I've tried loads, but the only one that I have semi-moved to recently is Fork.
ryeguy_24 2y ago
I’ve seen so much content on the Internet dedicated to how hard Git is to understand the moment you get beyond basic functionality. Is Git the problem or is meant to be used only after months of training and practice? Seems silly to have any software take so long to learn and comprehend.
- 112233 2y ago
  Training won't help: you need to be fighting wild git beasts almost daily, otherwise it all evaporates. Any modern dev work takes up 500% of your brain already. You pull, push, commit and stash all the time and it becomes second nature. Then, suddenly: your stash pop has failed! Something has been left somewhere! You need to git add something! Output of git diff is empty! Why is it empty, did stash not apply at all? (you run git stash pop second time, and feel terror) It recomends you to run git restore --staged! Was restore not kinda reset that wipes your local changes? Stash was your safe space, the only git thing you felt sure about. You feel abandoned. Next time, build script breaks only for you! No idea why! Turns out a day later the script cannot deal with worktrees you set up last year when you tried to "learn git" Some time later lead emails about "scrubbing prod creds", "force pushing HEAD". You run attached commands with fear and awe. Next month, you end up with a detached head! It sounds painful! Half stuff does not work! Gradually you are being conditioned that git equals pain. Sure, other tools have it worse (hi ffmpeg!), but they don't spring it on you in a middle of a big change you are trying to keep in your head, only to be forced to take a sabbatical and learn seven circles of reset because a wild tag merge conflict has appeared, or your lead wants you to use rerere to rebase your branch after splitting one commit into three.
  - nottoohard 2y ago
    Hey, so, these are not problems unique to git, for what it's worth. And if people don't want to deal with problems, then maybe software development isn't for them, because this is like a plumber complaining about joining pipes. (And don't bother belaboring this analogy, because I will not respond.)
    - 2y ago
HNSupportsUA 2y ago
[flagged]
subpixel 2y ago
I was an English major and generally do not have the gift that makes programming come naturally. What skills I have, including passing Git proficiency, are the result of brute force learning, plus years of mistakes. So I naturally assumed I could teach a team of non-engineers enough Git to enable them to interact with and contribute to text-only repositories as their job required. I was quite wrong. Git flummoxes some people, and even the best visual tutorials (the ones that helped me immensely), leave some more confused than when they started. YMMV but explaining simple Git concepts over and over in the face of incomprehension made me a bit of a dick too.
- bsder 2y ago
  Teach jj (jujutsu) instead. The idiocy that is "staging" is the primary problem with Git. 99% of people do not need "staging" and yet Git inflicts it on everybody. "Staging" (and "stash") makes Git modal, and that's a pain in the ass. Having taught people both Mercurial and Git, I can tell you that teaching Git is simply a losing battle. Fortunately, jj operates just like Mercurial but can coexist in the Github ecosystem.
  - starsixtynine 2y ago
    [flagged]
  - wingerlang 2y ago
    What is wrong with staging? I don't even consider staging until it is time to commit, at which point it is a little area to gather the exact changes you need.
    - sunshowers 2y ago
      Staging is an extra concept that adds complexity. Jujutsu shows you can achieve all the power of a staging area with strictly fewer concepts.
      - wingerlang 2y ago
janosch_123 2y ago
Oooh! I am literally talking to game devs today for ways to visualise knowledge about + Lithium batteries + Battery management systems + Embedded coding + CAN-Bus communication + Inverters & DC DC converters I made my own electric cars and am now sharing everything I learnt in a series of mini games & flashcard trainers. Duolingo for learning energy tech: https://foxev.io/academy/ https://foxev.io/academy/ There are so many abstract concepts that could easily be taught with a string of 2-3 Minigames that don't have to be harder than the average balloon pop game or a portal2 puzzle. A while ago I played a little game that taught you vim commands and let you traverse an RPG style landscape doing it.
- gunian 2y ago
  isvteaching people really that hard? the older i get and the more i see attempts at teaching i wonder why just teaching simply is hard
  - janosch_123 2y ago
    Putting content in the right order and hitting the right abstraction level. Keeping the reader/user in the zone between being bored and overwhelmed while you teaching them, without knowing something about them (only data as feedback if they are using a tool that you built,rather than them raising eyebrows or nodding in a classroom). I think it's hard but also fun. For the EV stuff that I look at there are a few problems compounding this: + Overwhelming buzzwords and complexity + Wrong intuition for HV systems + Unclear where to start + Capital requirements are high + Dangerous tech
    - starsixtynine 2y ago
      [flagged]
      - fragmede 2y ago
        do adults not get bored or overwhelmed?
    - 2y ago
fsloth 2y ago
Git is bad. Super bad. It's brilliant for it's original purpose of managing diffs in an open source project. For industrial projects that are not organized like an open source project it's a massive, massive footgun and it saddens me it remains some sort of badge of honour to memorize it's incomprehensible UI. It saddens me even more it's the goto vcs system even for industrial projects.
- loloquwowndueo 2y ago
  What would you suggest instead of git, if a hypothetical organization came and asked you which vcs to use other than git? Assume git interoperability is not necessary, to obviate the “we must be compatible with what our dependencies/upstreams use” argument.
  - metabagel 2y ago
    My company uses Perforce, and while it's not perfect, it's more intuitive and has a comprehensive graphical user interface. Most importantly, once I learn how to do something with Perforce, I never forget it. That's not the case for me with git. The merge tool works pretty well. Also, my company has large repositories.
    - fsloth 2y ago
      This. There are other options.
  - cliffordc 2y ago
    Subversion is still an excellent choice.
- nottoohard 2y ago
  [flagged]
- __loam 2y ago
  I use like 5 commands on a day to day basis. If you think that's incomprehensible then maybe this isn't the right career. I'm actually shocked to see this many comments on this site with this opinion. Maybe that's a sign that there's just a lot of charlatans here.
absoluteunit1 2y ago
I’ve been programming by professionally for about ~5years and using git for version control that entire time. When I deliberately spent time to learn the foundations of it, it blew my mind how incredibly sophisticated it is and how intuitive it becomes once you understand the core ideas behind it Highly encourage reading through the official documentation and Julia Evans blog posts on git.
QuadrupleA 2y ago
Sort of repeating a nested comment, but - I've been using fossil ( https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki ) for years and absolutely love it. Single executable you just download and put in your path. Sane, well-documented interface (CLI, API and web). Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. Easy exports to git/github. I think it's kind of a tragedy the dev world got so stuck on git.
- starsixtynine 2y ago
  [flagged]
  - QuadrupleA 2y ago
    Maybe just my present frustration, but I spent the day revising the Aider AI editor's code because it barely even works without git. It relies on git just to list the files in a directory, and so turns off most of it's cool features if there's no repo in it. I fixed it (PR coming) with some simple non-git directory traversal functions, which enables the cool features again. But makes me wish the dev world knew git alternatives exist.
jpat 2y ago
Neat game. You might want to check out this other git teaching game - https://learngitbranching.js.org/ https://learngitbranching.js.org/
- initialcommit 2y ago
  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.
osigurdson 2y ago
I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals but it does what I need so not compelled to dig deeper.
- Vaslo 2y ago
  This is a point that is not made enough. Git can be overly complicated if you want it to be. But 99% of your work is add, committing, branching and resetting. If you can do that you can probably never need much more. I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
  - dailykoder 2y ago
    This. Maybe even more than 99% of the time you are fine. It's okay to struggle a day with a rare problem every now and then. Just don't be scared of it. There are enough resources out there to research them when you need them. Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works. Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
    - osigurdson 2y ago
      Agree. It only makes sense to be scared of it if direct pushes to master are allowed - that would be crazy. This + avoid long running branches and there isn't much to fear.
-__---____-ZXyw 2y ago
I wonder if the author of this considered using luanti (formerly minetest) as the engine, would have maybe saved some work? https://content.luanti.org/ https://content.luanti.org/ But perhaps they'd a good reason to go the route they did. Very interesting concept, anyway.
- initialcommit 2y ago
  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
commandersaki 2y ago
I upskilled significant in git playing the https://learngitbranching.js.org/ https://learngitbranching.js.org/ game.
- fragmede 2y ago
  so much this. It should be second nature too navigate got history and commits as this tutorial teaches you.
adastra22 2y ago
I’m still waiting for “I struggled with git, so I invented the next paradigm of DVCS so no one ever has to struggle with git anymore.”
- WolfeReader 2y ago
  Fossil, Mercurial, Jujutsu. All have better CLIs and consistent behavior.
  - esafak 2y ago
    If only IDEs and sites like GitHub and GitLab were agnostic about the DVCS.
    - hikarikuen 2y ago
      It's not quite what you're asking for, but Jujutsu+Git is still a much better dev experience than Git alone and is completely compatible with those sites. I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :) ...I think my PRs have gotten noticeably cleaner and easier to review, though!
  - adastra22 2y ago
    Lipstick on a pig, I'm sorry to say. Especially jujutsu which is literally just a wrapper for git. These tools have better CLI for sure, and some nice added features too. VCS-integrated collaboration tools in fossil is nice. But my point was more along the lines of "why don't we have a radically different architecture that is better matched to the problem domain?"
    - martinvonz 2y ago
      We have database-backed storage backends for Jujutsu at Google. There's no Git involved there. So I think it's wrong to say that it's a wrapper for Git. Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.
tvb12 2y ago
I recognize that URL! Git-sim is so cool!
- initialcommit 2y ago
  Thank you! So glad it's been useful :D
oniony 2y ago
https://learngitbranching.js.org/ https://learngitbranching.js.org/ is very good for learning how Git branching works. Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.
- initialcommit 2y ago
  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 https://www.youtube.com/watch?v=BF7FnK1Gml8
  - oniony 2y ago
    OMG, I was cracking up watching that. I kept thinking "this is such a high effort piss take" only for it to finally dawn on me that it wasn't. W.I.T.A.F.
    - initialcommit 2y ago
      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 ;)
pixelpoet 2y ago
Damn, that's the last time I express any dissenting views about git. Haven't quite learnt my lesson yet, please pile on more downvotes.
fragmede 2y ago
git is one of those things thing that separates programmers from software engineers and I will die on that hill.
27theo 2y ago
> So much so that I impulse-bought the domain gitcraft.com for $2,660.16 ...
- initialcommit 2y ago
  Questionable decision on my part! :D
gacmachine1 2y ago
love the visual look - what inspired it OP?
lqet 2y ago
I also struggled with Git many years ago. Then I read the excellent "Version Control with Git" in 2014. Never looked back. It does an excellent job in connecting the Git commands to various basic operation on the commit graph. [0] https://www.oreilly.com/library/view/version-control-with/9781492091189/ https://www.oreilly.com/library/view/version-control-with/97...
ranscendental50 2y ago
This may sound a little weird, but I quite enjoyed the doom style way of exploring the repo. I wish it had been developed further. There was nothing stressful about it : ))

246 points by initialcommit 2y ago

pestatije 2y ago

everybody does...instead of playing games lets put the worshiping to one side and start using alternatives

mopsi 2y ago
What alternatives do you recommend?
- zabzonk 2y ago
  mercurial was arguably better - but switching to it is probably a bit silly now
  - mdaniel 2y ago
    I haven't tried it in a while, but mercurial supports reading and writing to git repos: https://wiki.mercurial-scm.org/HgGit https://wiki.mercurial-scm.org/HgGit and its page says that https://wiki.mercurial-scm.org/GitExtension https://wiki.mercurial-scm.org/GitExtension is bundled, but doesn't handle all of git's features
  - convolvatron 2y ago
    why? I had to stop using it because no one else would, and the various centralized services dropped support for it. but it handled branching and merging much better, was easier to pick up, and was less likely to trash your local checkout. maybe if someone rewrote it in rust it would be sexy again? rurcurial?
    - DrinkyBird 2y ago
      You jest, but… https://mercurial-scm.org/help/topics/rust#rhg https://mercurial-scm.org/help/topics/rust#rhg
    - BeetleB 2y ago
      > maybe if someone rewrote it in rust it would be sexy again? They have and it's called jujutsu :-) https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj OK, it's not a Mercurial clone, but it did take some features from it, and using it will feel more like Mercurial than git. And you can use it on git repositories, so you can have your cake and eat it too.
    - zabzonk 2y ago
      I think the loss of the google and bitbucket repositories was the main problem - i know that took the heart out of me for doing foss development. i can deal with git (shit, i can deal with rcs), but i don't like it.
  - DrinkyBird 2y ago
    Modern Mercurial with evolution is extremely pleasant, and the more I use it the more I abhor git whenever I have to go back to it. That plus Heptapod (fork of GitLab with Mercurial support) — it’s very nice indeed. I count myself lucky to mainly contribute to a project where we use all of this. It’s a shame there’s still nothing quite like GitHub for Mercurial (anymore), where anyone can just sign up and create repositories. Heptapod has a public instance for FOSS, but it requires approval to create projects. There’s also a separate hosted instance for basically anything, but it’s commercial and costs money. One can also self-host, but GitLab is not exactly lightweight, and other solutions aren’t as integrated with evolution features.
- forks 2y ago
  jujutsu: https://jj-vcs.github.io/jj/latest/ https://jj-vcs.github.io/jj/latest/
- lylejantzi3rd 2y ago
  ark: https://ark-vcs.com/ https://ark-vcs.com/
- wetpaws 2y ago
  [dead]
- Hikikomori 2y ago
  Gitbutler is great.
01HNNWZ0MV43FF 2y ago
I'll be a late adopter, go ahead without me :)
Etheryte 2y ago
Git is not good, but I'm yet to see anything that's a clear improvement without sacrificing on the core capabilities. Do you have any recommendations that you like?
- deleted 2y ago
  [deleted]
- Novosell 2y ago
  A lot of people love jujutsu/jj.
fHr 2y ago
it is already pretty good and far better than svn, mercurial
starsixtynine 2y ago
You first. :)
Nzen 2y ago
Is there an alternative that keeps the stage(/index) concept ? I acknowedge that the inconsistent argument style looks clumsy when remembering `git log --name-only --oneline`. However, I value the workflow afforded by the stage: I can keep work for several tasks in my workspace until I am ready to commit them. I've checked Fossil, Jujutsu, and Mercurial. Each disavows the stage. I understand that it takes more discipline (and I occasionally fail to adhere to that discipline). But, I'm not interested in the other features of a vcs if it forces me to work on only one thing at a time.
- WolfeReader 2y ago
  In Mercurial, you are ideally using TortoiseHg. When you make a commit, you can quite easily choose which files or hunks or lines to commit (and which not to commit, obviously). In that sense, the GUI acts as the staging area. For Jujutsu, there's two good options I know of: 1. Use "jj commit -i". This opens up a screen which lets you interactively select files/hunks/lines to commit. You can also pass in a "--tool" commit to use something like Meld. 2. Use the "squash workflow" - basically making your own staging area using jj's flexibility. I can't explain it better than Steve does: https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
  - WolfeReader 2y ago
    Oh, and if you think JJ "forces you to work on one thing at a time" then you have really missed a lot of what JJ offers. Look up "megamerge" - I've done this, and it works well. Here's a link: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...

mjburgess 2y ago

The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic. Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.

quickslowdown 2y ago
I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually. I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
- irrational 2y ago
  If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
  - perching_aix 2y ago
    I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
  - eddd-ddde 2y ago
    No, they said that for a git newbie, a gui will be easier.
  - quickslowdown 2y ago
    I never said if you're not using the CLI then you're a noob. I'm talking about people new to git in general.
- 2y ago

ctxcode 2y ago

how i've used git every day in the last 10 years: git add -A, git commit -m, git push If there's an error because there are changes on the remote, type: git pull, fix conflicts in case there are any, repeat previous commands In all other cases, google/grok for the solution, doesnt happen often.

graypegg 2y ago
Not to be annoying, but maybe one of the most useful things git does for me outside of the usual SCM stuff, is git-bisect. Its saved me many hours of debugging. If you ever run into a case where something is broken (that you can measure, like a test or broken build) but it’s not obvious what change caused the fault, first go to a commit where you know the fault is present. $ git bisect start $ git bisect bad Then go to a commit where you know the fault is NOT present. Go back far if you can! This can be in another branch as long as your start and end spots are connected somehow. $ git checkout abc123 $ git bisect good And after that bisect command, your HEAD will get moved to the mid point between the good and bad commits. Check if the fault is still there, and run either "git bisect good" or "git bisect bad" depending on if it’s resolved or not. It will keep jumping you to the mid point between the nearest bad commit and good commit till you end up at 1 precise commit that caused your fault. This works extremely well for configuration changes specifically, where maybe it doesn’t break in CI, but on your local dev machine it does. You can also use this for non-text files like images to find out when 1 part of an image was changed for example. — Also if you just want to make normal SCM stuff easier, $ git commit -Am "…" For a combo add-everything+commit
- pigcat 2y ago
  Thanks for explaining this so clearly! I'm going to try this next time :)
initialcommit 2y ago
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 :)

bloomingkales 2y ago

The only winning move is not to play. Stick to a few git commands (3-4) and there won't be a whole Alice in Wonderland journey down the rabbit hole.

initialcommit 2y ago
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
- bloomingkales 2y ago
  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.
  - initialcommit 2y ago
    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.
    - deleted 2y ago
      [deleted]
    - deleted 2y ago
      [deleted]
    - nottoohard 2y ago
      [flagged]
  - 2y ago

syntaxing 2y ago

I'm actually surprised how many Software Engineers/Developers don't know how to use Git... I was once showing a Staff SWE on how to setup VScode + Python. I see kinda why when you're programming in vim + C(++) your whole career. But when I told him to push his changes to a temp branch or give me a git diff so I can try his changes myself, he had zero clue what I was talking about. His local `main` was over 2 months old. We had to prune and pull to get it back to match remote. A funner part of the story, I was showing him how to setup VScode because programming using VScode...through RDP. That's right, he was programming remotely on the remote machine using RDP with VScode on the remote screen.

initialcommit 2y ago
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.
graypegg 2y ago
So on the other side of this, I’ve also seen senior+ folk working on projects alone, with no collaboration at all, but still use a GitHub-esque PR/git-flow process. Almost feels like a professionalism-espousing self-flagellation. Create a PR, self-approve the PR, then merge it to a develop branch. Then merge the develop branch into main. Then in main make a release branch, and tag it.
- booleandilemma 2y ago
  I'm guilty of this. I open PRs on my personal projects and then merge them in myself. Not for every commit of course, but for the big changes. I just like to see the diffs on the github UI. <shrug>

mlhpdx 2y ago

Oh how I love a good game UX for DevOps.

fHr 2y ago

git is paradise, I now have to use svn, fuck that shit

bigstrat2003 2y ago
I'd much rather use SVN than git. I only grudgingly tolerate git because of network effects, otherwise I'd still happily be using SVN.
_flux 2y ago
Perhaps git-svn works for you?
rho4 2y ago
I have been happily using that shit daily for 20+ years now.

whoateallthepy 2y ago

I learned Git from an O'Reilly book and I loved that it started with the internals first. The git CLI has some rough edges, but once you have concepts of work tree, index, commits and diffs down, it is extremely powerful. magit in Emacs is also incredible.

nottoohard 2y ago
[flagged]
initialcommit 2y ago
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?
- fragmede 2y ago
  https://learngitbranching.js.org/ https://learngitbranching.js.org/ is my go-to recommendation
pxmpxm 2y ago
Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it. None of the concepts behind git are difficult to grasp, the problem is interface and leaky abstractions all over. Any person that mentions reflogs is actually saying I don't understand any of the points above.
- skydhash 2y ago
  > Ah yes, the hallmark of great software is having to learn how it's implemented to be able to use it. Because learning how a software model a particular problem domain is a great step towards efficient use? You can hope it's magic, but that's a recipe for failure if you're a heavy user. Every professional learns the ins and outs of the tools he uses often.
  - 2y ago

hk1337 2y ago

The main thing I struggle with in git is the habit of “make a change, make a commit”. I will often do multiple commits but they will be all at once as I go through and make a commit and include any relevant changes in the commit.

rectang 2y ago
I find that the command "git add -p", which allows you to add individual sections of files rather than whole files before committing, helps with this issue. It's quite natural to wind up with a bunch of work that really needs to be in multiple commits. I don't think this ever changes for most of us.
- hk1337 2y ago
  That’s basically what I do, I just end up doing it in large spurts. I typically use the cli for most things but I like the GitHub app for picking out changes for a particular commit.

digdugdirk 2y ago

Does anyone use Fossil source control? I've always been interested by it, but it just seems to stay under the radar. I'm curious if there's a functional reason for that, or if github just got to be good enough.

graypegg 2y ago
Fossil is the SQLite one right? I would love to try alternatives SCM tools, but you run into the fact that associated tooling is so concentrated on git and its processes. I was using bitbucket and mercurial for a while! If fossil had something similar (which off the top of my head, I think they do? Something wiki-like for the SQLite project) I would be willing to mess around with it on a small team or something.
QuadrupleA 2y ago
Been using it for years and absolutely love and highly recommend it. Single executable you just download and put in your path. Sane, well-documented interface. Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. I think it's kind of a tragedy the dev world got so stuck on git. Maybe not too late!

fragmede 2y ago

The problem is I can't forget everything I know about git and approach it with fresh eyes to see if this is good or bad.

cube2222 2y ago

You may also consider using the Jujutsu VCS[0] as effectively a nicer and saner git frontend. I’ve written an intro to it a couple weeks back[1] - I’ve been using it since, and so far haven’t had the need to switch back to git at any point. [0]: https://jj-vcs.github.io/jj/latest/ https://jj-vcs.github.io/jj/latest/ [1]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/ https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

CharlieDigital 2y ago
This one is probably the best intro I've read: https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/ Really, really good examples and walkthroughs with easy to understand, animated console sessions that show real-world-ish use cases including conflict resolution and why JJ's model makes it easier. Really good read and easy to digest because of the animated session replays. My main takeaway is that the missing pieces right now are IDE support for a world filled with detached heads and a foolproof upstream integration pattern on `push` (requires a bit of manual work to designate the target branch).
- bthallplz 2y ago
  Regarding IDE support, you might be interested in this VS Code extension: https://github.com/keanemind/jjk https://github.com/keanemind/jjk I found it today and like it quite a bit. The Visual JJ extension (https://www.visualjj.com https://www.visualjj.com) is also good, but JjK feels more integrated to me.
  - CharlieDigital 2y ago
    Nice; thanks for sharing this.
stouset 2y ago
I am 100% going to link to the original post and these replies next time there’s a jj thread and people express bewilderment about needing anything else because “git is so simple”.

nickandbro 2y ago

Kinda reminds me of https://ohmygit.org/ https://ohmygit.org/

initialcommit 2y ago
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.
- initialcommit 2y ago
  It can basically do all this: https://www.youtube.com/watch?v=BF7FnK1Gml8 https://www.youtube.com/watch?v=BF7FnK1Gml8

CLiED 2y ago

I used to struggle with git until I started to use a GUI, now it just works but I get far less hacker cred therefor, which is regrettable.

rectang 2y ago
Heh. I care about results from my colleagues and collaborators, not their tool preferences. If your topic branches and commit messages make sense, that's what matters — because those are our touch points of collaboration.
metabagel 2y ago
Which GUI?
- wingerlang 2y ago
  Not OP, but I've been using SourceTree for over a decade. I've tried loads, but the only one that I have semi-moved to recently is Fork.

ryeguy_24 2y ago

I’ve seen so much content on the Internet dedicated to how hard Git is to understand the moment you get beyond basic functionality. Is Git the problem or is meant to be used only after months of training and practice? Seems silly to have any software take so long to learn and comprehend.

112233 2y ago
Training won't help: you need to be fighting wild git beasts almost daily, otherwise it all evaporates. Any modern dev work takes up 500% of your brain already. You pull, push, commit and stash all the time and it becomes second nature. Then, suddenly: your stash pop has failed! Something has been left somewhere! You need to git add something! Output of git diff is empty! Why is it empty, did stash not apply at all? (you run git stash pop second time, and feel terror) It recomends you to run git restore --staged! Was restore not kinda reset that wipes your local changes? Stash was your safe space, the only git thing you felt sure about. You feel abandoned. Next time, build script breaks only for you! No idea why! Turns out a day later the script cannot deal with worktrees you set up last year when you tried to "learn git" Some time later lead emails about "scrubbing prod creds", "force pushing HEAD". You run attached commands with fear and awe. Next month, you end up with a detached head! It sounds painful! Half stuff does not work! Gradually you are being conditioned that git equals pain. Sure, other tools have it worse (hi ffmpeg!), but they don't spring it on you in a middle of a big change you are trying to keep in your head, only to be forced to take a sabbatical and learn seven circles of reset because a wild tag merge conflict has appeared, or your lead wants you to use rerere to rebase your branch after splitting one commit into three.
- nottoohard 2y ago
  Hey, so, these are not problems unique to git, for what it's worth. And if people don't want to deal with problems, then maybe software development isn't for them, because this is like a plumber complaining about joining pipes. (And don't bother belaboring this analogy, because I will not respond.)
  - 2y ago

HNSupportsUA 2y ago

[flagged]

subpixel 2y ago

I was an English major and generally do not have the gift that makes programming come naturally. What skills I have, including passing Git proficiency, are the result of brute force learning, plus years of mistakes. So I naturally assumed I could teach a team of non-engineers enough Git to enable them to interact with and contribute to text-only repositories as their job required. I was quite wrong. Git flummoxes some people, and even the best visual tutorials (the ones that helped me immensely), leave some more confused than when they started. YMMV but explaining simple Git concepts over and over in the face of incomprehension made me a bit of a dick too.

bsder 2y ago
Teach jj (jujutsu) instead. The idiocy that is "staging" is the primary problem with Git. 99% of people do not need "staging" and yet Git inflicts it on everybody. "Staging" (and "stash") makes Git modal, and that's a pain in the ass. Having taught people both Mercurial and Git, I can tell you that teaching Git is simply a losing battle. Fortunately, jj operates just like Mercurial but can coexist in the Github ecosystem.
- starsixtynine 2y ago
  [flagged]
- wingerlang 2y ago
  What is wrong with staging? I don't even consider staging until it is time to commit, at which point it is a little area to gather the exact changes you need.
  - sunshowers 2y ago
    Staging is an extra concept that adds complexity. Jujutsu shows you can achieve all the power of a staging area with strictly fewer concepts.
    - wingerlang 2y ago

janosch_123 2y ago

Oooh! I am literally talking to game devs today for ways to visualise knowledge about + Lithium batteries + Battery management systems + Embedded coding + CAN-Bus communication + Inverters & DC DC converters I made my own electric cars and am now sharing everything I learnt in a series of mini games & flashcard trainers. Duolingo for learning energy tech: https://foxev.io/academy/ https://foxev.io/academy/ There are so many abstract concepts that could easily be taught with a string of 2-3 Minigames that don't have to be harder than the average balloon pop game or a portal2 puzzle. A while ago I played a little game that taught you vim commands and let you traverse an RPG style landscape doing it.

gunian 2y ago
isvteaching people really that hard? the older i get and the more i see attempts at teaching i wonder why just teaching simply is hard
- janosch_123 2y ago
  Putting content in the right order and hitting the right abstraction level. Keeping the reader/user in the zone between being bored and overwhelmed while you teaching them, without knowing something about them (only data as feedback if they are using a tool that you built,rather than them raising eyebrows or nodding in a classroom). I think it's hard but also fun. For the EV stuff that I look at there are a few problems compounding this: + Overwhelming buzzwords and complexity + Wrong intuition for HV systems + Unclear where to start + Capital requirements are high + Dangerous tech
  - starsixtynine 2y ago
    [flagged]
    - fragmede 2y ago
      do adults not get bored or overwhelmed?
  - 2y ago

fsloth 2y ago

Git is bad. Super bad. It's brilliant for it's original purpose of managing diffs in an open source project. For industrial projects that are not organized like an open source project it's a massive, massive footgun and it saddens me it remains some sort of badge of honour to memorize it's incomprehensible UI. It saddens me even more it's the goto vcs system even for industrial projects.

loloquwowndueo 2y ago
What would you suggest instead of git, if a hypothetical organization came and asked you which vcs to use other than git? Assume git interoperability is not necessary, to obviate the “we must be compatible with what our dependencies/upstreams use” argument.
- metabagel 2y ago
  My company uses Perforce, and while it's not perfect, it's more intuitive and has a comprehensive graphical user interface. Most importantly, once I learn how to do something with Perforce, I never forget it. That's not the case for me with git. The merge tool works pretty well. Also, my company has large repositories.
  - fsloth 2y ago
    This. There are other options.
- cliffordc 2y ago
  Subversion is still an excellent choice.
nottoohard 2y ago
[flagged]
__loam 2y ago
I use like 5 commands on a day to day basis. If you think that's incomprehensible then maybe this isn't the right career. I'm actually shocked to see this many comments on this site with this opinion. Maybe that's a sign that there's just a lot of charlatans here.

absoluteunit1 2y ago

I’ve been programming by professionally for about ~5years and using git for version control that entire time. When I deliberately spent time to learn the foundations of it, it blew my mind how incredibly sophisticated it is and how intuitive it becomes once you understand the core ideas behind it Highly encourage reading through the official documentation and Julia Evans blog posts on git.

QuadrupleA 2y ago

Sort of repeating a nested comment, but - I've been using fossil ( https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki ) for years and absolutely love it. Single executable you just download and put in your path. Sane, well-documented interface (CLI, API and web). Full repo in a single SQLite file. Highly intelligent and efficient diff-based storage and compression (including network transfers). Rock-solid code. Easy exports to git/github. I think it's kind of a tragedy the dev world got so stuck on git.

starsixtynine 2y ago
[flagged]
- QuadrupleA 2y ago
  Maybe just my present frustration, but I spent the day revising the Aider AI editor's code because it barely even works without git. It relies on git just to list the files in a directory, and so turns off most of it's cool features if there's no repo in it. I fixed it (PR coming) with some simple non-git directory traversal functions, which enables the cool features again. But makes me wish the dev world knew git alternatives exist.

jpat 2y ago

Neat game. You might want to check out this other git teaching game - https://learngitbranching.js.org/ https://learngitbranching.js.org/

initialcommit 2y ago
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.

osigurdson 2y ago

I don't really understand struggles with git. I learned ~10 commands 15 years ago which have worked fine for me. I don't think I deeply understand git internals but it does what I need so not compelled to dig deeper.

Vaslo 2y ago
This is a point that is not made enough. Git can be overly complicated if you want it to be. But 99% of your work is add, committing, branching and resetting. If you can do that you can probably never need much more. I will say though that I get really nervous reverting sometimes, making sure I’m using the right command to reset etc can be confusing.
- dailykoder 2y ago
  This. Maybe even more than 99% of the time you are fine. It's okay to struggle a day with a rare problem every now and then. Just don't be scared of it. There are enough resources out there to research them when you need them. Where I still get nervous is when I force push my branch after a rebase, even if I know I am the only one working on it. But this is also one of these examples. If I remember correctly, there are other options to sync your remote after you did a rebase, but force push is just the easiest. So I rather take 5 seconds to make sure I typed exactly what I wanted and that everything is fine and that just works. Edit: I was just brainstorming a bit about it and thought that probably some of the unknown magic git features were just implemented by a motivated dev that just wanted to explore what's possible. But on the other hand, there are most likely some very very obscure configurations and edge cases in the wild where people actually need those features. But most people will likely never need them, so I myself won't bother understanding "everything"
  - osigurdson 2y ago
    Agree. It only makes sense to be scared of it if direct pushes to master are allowed - that would be crazy. This + avoid long running branches and there isn't much to fear.

-__---____-ZXyw 2y ago

I wonder if the author of this considered using luanti (formerly minetest) as the engine, would have maybe saved some work? https://content.luanti.org/ https://content.luanti.org/ But perhaps they'd a good reason to go the route they did. Very interesting concept, anyway.

initialcommit 2y ago
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

commandersaki 2y ago

I upskilled significant in git playing the https://learngitbranching.js.org/ https://learngitbranching.js.org/ game.

fragmede 2y ago
so much this. It should be second nature too navigate got history and commits as this tutorial teaches you.

adastra22 2y ago

I’m still waiting for “I struggled with git, so I invented the next paradigm of DVCS so no one ever has to struggle with git anymore.”

WolfeReader 2y ago
Fossil, Mercurial, Jujutsu. All have better CLIs and consistent behavior.
- esafak 2y ago
  If only IDEs and sites like GitHub and GitLab were agnostic about the DVCS.
  - hikarikuen 2y ago
    It's not quite what you're asking for, but Jujutsu+Git is still a much better dev experience than Git alone and is completely compatible with those sites. I use Jujutsu for 100% of my version control at my day job, where all of our repos are in Bitbucket and all my coworkers are using Git. AFAIK most of my coworkers don't even know I'm doing anything different, other than those who I've "evangelized" so far :) ...I think my PRs have gotten noticeably cleaner and easier to review, though!
- adastra22 2y ago
  Lipstick on a pig, I'm sorry to say. Especially jujutsu which is literally just a wrapper for git. These tools have better CLI for sure, and some nice added features too. VCS-integrated collaboration tools in fossil is nice. But my point was more along the lines of "why don't we have a radically different architecture that is better matched to the problem domain?"
  - martinvonz 2y ago
    We have database-backed storage backends for Jujutsu at Google. There's no Git involved there. So I think it's wrong to say that it's a wrapper for Git. Even when using the Git backend, it's only commits and lower-level objects that are stored in the Git repo, and even some parts of the commits are stored outside Git (e g. the change ID). The operation log (which powers the undo feature) is also not stored in Git.

tvb12 2y ago

I recognize that URL! Git-sim is so cool!

initialcommit 2y ago
Thank you! So glad it's been useful :D

oniony 2y ago

https://learngitbranching.js.org/ https://learngitbranching.js.org/ is very good for learning how Git branching works. Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.

initialcommit 2y ago
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 https://www.youtube.com/watch?v=BF7FnK1Gml8
- oniony 2y ago
  OMG, I was cracking up watching that. I kept thinking "this is such a high effort piss take" only for it to finally dawn on me that it wasn't. W.I.T.A.F.
  - initialcommit 2y ago
    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 ;)

pixelpoet 2y ago

Damn, that's the last time I express any dissenting views about git. Haven't quite learnt my lesson yet, please pile on more downvotes.

fragmede 2y ago

git is one of those things thing that separates programmers from software engineers and I will die on that hill.

27theo 2y ago

> So much so that I impulse-bought the domain gitcraft.com for $2,660.16 ...

initialcommit 2y ago
Questionable decision on my part! :D

gacmachine1 2y ago

love the visual look - what inspired it OP?

lqet 2y ago

I also struggled with Git many years ago. Then I read the excellent "Version Control with Git" in 2014. Never looked back. It does an excellent job in connecting the Git commands to various basic operation on the commit graph. [0] https://www.oreilly.com/library/view/version-control-with/9781492091189/ https://www.oreilly.com/library/view/version-control-with/97...

ranscendental50 2y ago

This may sound a little weird, but I quite enjoyed the doom style way of exploring the repo. I wish it had been developed further. There was nothing stressful about it : ))