[HN Gopher] I struggled with Git, so I'm making a game to spare ...
___________________________________________________________________
I struggled with Git, so I'm making a game to spare others the pain
Author : initialcommit
Score : 106 points
Date : 2025-03-02 14:18 UTC (8 hours ago)
(HTM) web link (initialcommit.com)
(TXT) w3m dump (initialcommit.com)
| pestatije wrote:
| everybody does...instead of playing games lets put the worshiping
| to one side and start using alternatives
| mopsi wrote:
| What alternatives do you recommend?
| zabzonk wrote:
| mercurial was arguably better - but switching to it is
| probably a bit silly now
| mdaniel wrote:
| I haven't tried it in a while, but mercurial supports
| reading and writing to git repos: https://wiki.mercurial-
| scm.org/HgGit and its page says that
| https://wiki.mercurial-scm.org/GitExtension is bundled, but
| doesn't handle all of git's features
| convolvatron wrote:
| 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 wrote:
| You jest, but... https://mercurial-
| scm.org/help/topics/rust#rhg
| BeetleB wrote:
| > 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
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| jujutsu: https://jj-vcs.github.io/jj/latest/
| lylejantzi3rd wrote:
| ark: https://ark-vcs.com/
| Hikikomori wrote:
| Gitbutler is great.
| 01HNNWZ0MV43FF wrote:
| I'll be a late adopter, go ahead without me :)
| Etheryte wrote:
| 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?
| fHr wrote:
| it is already pretty good and far better than svn, mercurial
| mjburgess wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nlawalker wrote:
| Amen. The ever-present insistence that the command line is the
| only way to use git is the modern version of "ed is the
| standard text editor"[1]
|
| https://www.gnu.org/fun/jokes/ed-msg.html
| pixelpoet wrote:
| Bothers me a lot that you're getting downvoted. Bunch of
| elitists who insist that cmdline is only way to get things
| done (everyone has to study cmdline options because who could
| possibly have multiple 4k screens for some visual options
| dialog?), probably using GDB in 2025 and having massive
| Stockholm syndrome about it, ...
| skeeter2020 wrote:
| I don't consider myself a very core or talented developer,
| but I do feel quite strongly that git from the cmd line is
| much easier than a GUI, but overall ridiculously hard
| regardless. The abstractions and visualizations in
| graphical interfaces is either too dense & complicated, or
| more likely hides what's actually happening; there's no way
| to reduce the inherient complexity.
|
| My take: don't play the game. learn your basic required
| workflow from the command line and use the decent
| documentation to look up everything else.
| mjburgess wrote:
| NB. I did explicitly say a GUI on top of a cli app is a
| broken approach. Your intuition comes from this -- that
| the git API is cli-first.
|
| Source control should be designed graphically first, with
| a cli to automate. I routinely use tree-view and column
| view in macos finder to think-through fs organisation --
| doing this as a sequence of cli commands would be
| masochistic.
|
| Notice how all the best vcs tutorials are just providing
| basic visuals which would be better as the interface.
| skydhash wrote:
| The thing that CLI have over GUI is programmability,
| which for programmers is a valuable property. As for me,
| any repeatable task, I automate away with various degree
| of effort and quality. If I find myself needing a
| particular set of commands and flag, I create an alias, a
| function, or a shell script for that, like `flac2mp3.sh`
| instead of hunting down through the shell history.
|
| For most vcs tutorial, they don't often use why the
| history of changes is important, instead focusing on a
| set of usual commands. Why, not how. Once you have that
| philosophy down, the tool usage become much more
| efficient.
| dingnuts wrote:
| I've been using magit for almost a decade now and it
| directly contradicts what you're saying simply by
| existing and being as awesome as it is
| perching_aix wrote:
| I'm one of those folks who will tell people to give the
| official CLI frontend of git a chance and to try and stick
| to it. I can assure you it is not out of elitism, but
| experience. I've tried the many third party GUI frontends,
| and always got myself into bigger trouble down the line in
| the end, nor did they bring any of the revelatory boosts in
| insight they claimed they would. And of course, they're all
| a little different from one another, so migrating between
| them is an additional chore.
|
| Then of course it's possible I didn't give the many GUI
| frontends enough of a chance. Such is life, it's a resource
| limited game. Principally, I justify my position with the
| argument that the many GUIs will try to translate git into
| something visual by adding their own designs, and this can
| prove additionally misleading and difficult, if git wasn't
| rough enough already.
|
| The only GUI bits I use for git are editor integrations
| such as the official one in VS Code, and only when I know
| it's adequate. Which you can only know if you know what's
| going on in the background.
| suzzer99 wrote:
| I work in a lot of repos at once. I do a lot of global
| search-and-replacing and random debugging. With SourceTree,
| I can easily see all the changes I've made across all repos
| in one glance.
|
| I can then drill down to each file with the visual diff and
| see whether the changes are something I want to check in,
| or just debugging. If it's debugging code, I can click
| "Discard Changes" to drop all changes I've made to that
| file. Or I can selectively discard a hunk or discard lines.
|
| When I show these features to command line purists, they
| always concede that this can't easily be done with the
| command line. So I don't see what's to gain if I'm losing
| those features, which I rely on constantly.
|
| I've been working in SourceTree for a decade, so I know all
| the quirks by now, which I pass on to any new devs who want
| to use it.
| rectang wrote:
| The following command provides a visualization which is good
| enough to start from: git log --oneline
| --graph
|
| The more practical problem is that Github, which provides a
| useful graphic UI to complement the local command line for any
| project hosted there, is brain dead[1] about showing the source
| control tree as a tree and doesn't expose anything like
| `--graph`.
|
| If you get tired of typing `git log --oneline --graph`, you can
| add a `git slog` alias[2] for it by adding the following in
| `~/.gitconfig`: [alias] slog =
| log --oneline --graph
|
| [1] Gitlab is superior in this aspect, as it actually exposes a
| graph mode, via "[repo] > Code > Repository Graph".
|
| [2] Or if you want to get fancy:
| https://github.com/rectang/dotfiles/blob/064b22c42846f8a3f18...
| timhh wrote:
| `git log --graph` is just a really really bad GUI. Why not
| use a good GUI instead?
|
| Although in fairness it's quite hard to find a good Git GUI
| because there are so many bad ones. The only good ones I've
| found all have some kind of flaw:
|
| * GitX - the clearest design IMO, but it's one of those
| "gazillion forks" bits of software like TomatoUSB, and Mac
| only. Plus it has some annoying bugs.
|
| * Git Extensions - I didn't even realise this was a Git GUI
| until relatively recently because it its terrible name. It's
| pretty decent, but Windows only.
|
| * VSCode 'Git Graph' extension - my current favourite - it
| integrates into VSCode too which is much better than a
| standalone app, especially when using Remote SSH. However it
| is abandonware and although the source is available, the
| license doesn't let you republish it so it's not "open
| source" and nobody can take it over.
|
| Disappointingly even these don't let you do things that a GUI
| obviously should let you do, like copy & pasting commits,
| dragging and dropping to rebase.
|
| Like instead of `git rebase -i` and tedious text edits, why
| can't I just ctrl-select some commits, ctrl-C and ctrl-V?
|
| But, they're still miles better than `git log --graph`.
| rectang wrote:
| `git log --graph` without `--oneline` is pretty hard to
| follow -- that's not what I use, and it's not what I
| suggested.
|
| _With_ `--oneline`, it 's not perfect but it's good enough
| to be useful -- and by working within the constraints of
| the CLI, I didn't have to tell people to install software
| to get my point across.
|
| And I already spoke approvingly of Gitlab's GUI for graph
| representation! I don't disapprove of GUIs; I use them all
| the time (particularly Github's). One you grok the data
| structures that underlie Git, you wind up seeing front ends
| as interchangeable.
| ozim wrote:
| I use Git Extensions since 2012 or something?
|
| I basically never used Git command line unless fixing some
| problems other people created.
|
| It is just insanity when people claim "only proper way is
| to use command line" - well yeah it is much faster if you
| work on your branch and just need to make quick series of
| commits. But as soon as you have to deal with collaboration
| with other people and organize project, coordinate features
| etc. I find GUI invaluable and Git Extensions of course.
| Tijdreiziger wrote:
| Chacon & Straub's _Pro Git_ , available for free online [1], is
| an excellent resource and has a lot of visual diagrams.
|
| [1] https://git-scm.com/book/en/v2
| rectang wrote:
| I love this book. It's what helped me move from an
| intermediate Git user to an advanced one, and I've
| subsequently trained a bunch of people at different
| organizations by going through it.
|
| However, _Pro Git_ is not an ideal resource for newbies
| unless they are highly motivated or receiving generous
| training. A simple graphical representation of your own repo
| goes a long way towards establishing a mental model of what
| Git is doing internally -- which is in my view the chief
| insight of mjburgess 's post at the top of this thread.
| Tijdreiziger wrote:
| You're probably right about that. I used a certain
| interactive online course when I was a beginner, but
| they've added "AI assistance for guided coding help", so I
| hesitate to recommend it.
|
| FWIW, the Git website links to some videos and external
| tutorials, which might be of use: https://git-scm.com/doc
| CamperBob2 wrote:
| 500 pages (excuse me, 501) to document a source control tool.
|
| Something went very wrong here early on. But, lacking a time
| machine and a handgun, it's clearly unfixable.
| Tijdreiziger wrote:
| The first 6-7 chapters should teach you more than most Git
| users know (myself included, suppose I might be due a re-
| read!).
| skydhash wrote:
| Which you can read easily in a week or two without much
| effort for something that is currently de facto for
| software development. The Emacs Manual has ~700 pages.
| metabagel wrote:
| This seems wildly optimistic.
| skeeter2020 wrote:
| I use this whenever I need to look up anything outside of our
| workflow, but don't believe internalizing the myriad of git
| details has a very high pay-off. There's probably higher
| value knowledge in your role that you should prioritize.
| rectang wrote:
| The payoff comes when you develop a mental model of Git's
| data structure design, which is stuff like "a branch is a
| named pointer to a commit" and "the central data structure
| is a content-addressable store" -- and most germane to this
| thread, "the source control tree is a diagram, and the
| operations one does to it are diagrammatic". (Thanks
| mjburgess!)
|
| Learning Git's infinity CLI options won't teach you that.
| fsloth wrote:
| Does not still fix the root cause that Git is super-bad as an
| industrial tool - actions that should be trivial push-button
| activities become incomprehensible command line character
| soup.
|
| The fact there is a _book_ on the subject speaks volumes
| about how bad it is.
| SketchySeaBeast wrote:
| That's really it. Could I use the CLI? Sure. Do I? Nope. Using
| a tool like Git Extensions makes it so much easier to visualize
| what's going on. I have enough on my mind, I don't need to make
| the branch/merge/commit process harder than it is.
| philipwhiuk wrote:
| This is why I've always liked gitk for anything non-trivial.
| ctxcode wrote:
| 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 wrote:
| 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 wrote:
| Thanks for explaining this so clearly! I'm going to try this
| next time :)
| initialcommit wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| credit_guy wrote:
| 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.
| delecti wrote:
| 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.
| never_inline wrote:
| I use the following commands frequently
|
| * pull
|
| * push
|
| * checkout / switch
|
| * commit (ofcourse)
|
| * merge
|
| But I will end up needing
|
| * log / log --stat
|
| * stash
|
| * diff
|
| * show / show --stat
|
| * blame
|
| * revert
|
| * cherry-pick
|
| * reset
|
| * git grep (can be replaced with rg / grep -rn)
|
| I can't imagine not having these commands now.
|
| If you use something frequently you should know it in-depth. It
| applies to tools (git, VSCode), frameworks (Spring, Django,
| whatever), infra (kubernetes, docker). otherwise you're missing
| out.
| mlhpdx wrote:
| > If you use something frequently you should know it in-
| depth.
|
| I prefer to remain oblivious to many things. Two views of the
| Mississippi and all that.
|
| Git works reliably and achieves my humble expectations.
| Thanks git.
|
| But in reality I use about the same set of commands. The
| exception being 'cherry-pick' which I avoid solely on
| disliking the name.
| fragmede wrote:
| what would you call it instead? or does the word cherry
| have some weird association in your mind?
| mlhpdx wrote:
| No, it's just weird and out of context. Just plain "pick"
| maybe.
| relaxing wrote:
| cherry picking has a negative connotation in its most
| common usage.
| initialcommit wrote:
| 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.
| rectang wrote:
| Version control is one of our main tools for interacting
| with other developers. Having a rich understanding of your
| version control software often helps to find solutions and
| workarounds for problems which would otherwise result in
| needless conflict.
| bloomingkales wrote:
| Core:
|
| - pull
|
| - push
|
| - commit/checkout
|
| - merge
|
| Quality of life:
|
| - stash
|
| - diff
|
| Asking for trouble:
|
| - revert
|
| - cherry-pick
|
| Your definition matches my mine of a tight subset of git.
| rochacon wrote:
| I would just add `git rebase -i` to the mix. Very useful to
| clean up a work branch before submitting it for others.
| Sometimes you just need a bunch of "wip" commits, e.g.
| testing CI scripts, deploying a optimization on the side for
| further testing, etc. and rebase is a must if you care about
| the commit log.
| Shacklz wrote:
| > Stick to a few git commands
|
| This was my approach for my first few years of git. I always
| tried to approach git via its commands, and I horribly failed -
| until I finally took a little bit of effort to understand how
| git actually works under the hood, which really made it click
| for me.
|
| For anyone who has ever spent a modicum of time (e.g. while
| getting a CS degree) trying to understand datastructures, it's
| probably really straight-forward to "get git". The
| datastructure underneath is really quite simple. A branch is a
| pointer to a commit, a commit is a pointer to a tree, a tree is
| a list of pointers to other trees and files. That's already
| pretty much all there is to it.
|
| Once the datastructure of git is understood, the commands start
| to "make sense" on their own - at least most of them. They
| still have tons of obscure options that one doesn't
| realistically need in a daily work flow, but the general idea
| what the commands do (and how to recover from screwups) was, at
| least for me, pretty simple after understanding the
| datastructure.
| syntaxing wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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>
| kimixa wrote:
| I sometimes do something similar, as it gives a chance for
| the CI to run more comprehensive tests on other platforms
| that's hooked up to the PR flow, and "reviewing" your own
| code can be pretty helpful.
| hk1337 wrote:
| I can see doing this, stepping away from the change for a
| bit, come back and read the PR from a fresh perspective and
| see if you can make sense of the change and if there are any
| errors.
|
| Also, the "paper trail" of PRs is nice to have.
| rectang wrote:
| I don't use pull requests because it seems higher ROI to just
| put that effort into crafting a good merge commit message.
|
| Aside from that, you've more or less described my workflow
| for solo projects.
| bloopernova wrote:
| I've known quite a few software engineers who just don't bother
| to learn anything about the tooling they use to create and
| deploy code. For younger, new developers, I can understand it
| when everything is presented as an app with minimal
| customization, but for mid-levels and senior engineers I am
| baffled by the lack of curiosity.
|
| Sometimes just a couple of simple howto sessions can be
| incredibly useful, especially for teams just starting on a new
| project. I've given tutorials on Git basics, command line
| basics, workflow basics, and AWS terminology. Each time I've
| had engineers say it was like learning computing for the first
| time, because apparently newer engineers just don't get taught
| this stuff.
|
| This is partly why I enjoy improving the developer "experience"
| (DevEx) alongside my normal DevOps duties.
| yodsanklai wrote:
| Maybe because they didn't use Git in their career or their role
| doesn't require to be hands-on.
|
| In my company, we use mercurial so I can imagine that some SWEs
| aren't fluent in Git because they've used different tools. But
| apart from that, Git isn't rocket science. It takes a bit of
| practice like anything else but anybody should be able to know
| the basics in a few days, and become proficient after a few
| months of regular practice.
| rectang wrote:
| I don't think that regular usage of the Git CLI is sufficient
| to develop an insight into Git's internal data design for
| most people, which is really necessary for to become
| proficient enough to troubleshoot. You wind up thrashing a
| lot and then just giving up.
| BurningFrog wrote:
| I've always used IntelliJ/PyCharm/Rubymine for my Git needs.
|
| That handles 98% of what I need to do. For the remainder I
| sometimes stumble pretty badly, but figure things out.
| rochacon wrote:
| As you highlight with the "VSCode over RDP" story later on the
| post, it doesn't stop on Git. Some people just don't care about
| learning their tools. RTFM? Hell no. There is no care for the
| "craft". Once they learn the very basic for their current need,
| they're done with it. We can also observe this behavior during
| coding, once "it works", they just push all changes and move
| forward to the next thing. No second thoughts if it could be
| simpler/there were unnecessary changes, no double check if
| there is missing cases, etc. "Someone will spot my wrongings
| during review".
|
| From the outside, it feels like "low effort" all around. But to
| be honest, I can't really blame who does this. For some, it is
| just a 9-5 job anyway and they prefer not think about these
| stuff outside that 9-5 space. Deep diving into their tools
| might look like "wasted time" on their view.
|
| A friend refered me to this great post a few days ago that
| touches on this subject: https://josvisser.substack.com/p/you-
| cant-teach-caring
| mlhpdx wrote:
| Oh how I love a good game UX for DevOps.
| fHr wrote:
| git is paradise, I now have to use svn, fuck that shit
| bigstrat2003 wrote:
| 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.
| whoateallthepy wrote:
| 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.
| initialcommit wrote:
| 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?
| pxmpxm wrote:
| 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 wrote:
| > _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.
| metabagel wrote:
| https://v5.chriskrycho.com/essays/jj-init/
|
| > The problems with Git are many, though. Most of all, its
| infamously terrible command line interface results in a
| terrible user experience. In my experience, very few
| working developers have a good mental model for Git.
| Instead, they have a handful of commands they have learned
| over the years: enough to get by, and little more. The
| common rejoinder is that developers ought to learn how Git
| works internally -- that everything will make more sense
| that way.
|
| This is nonsense. Git's internals are interesting on an
| implementation level, but frankly add up to an incoherent
| mess in terms of a user mental model. This is a classic
| mistake for software developers, and one I have fallen prey
| to myself any number of times. I do not blame the Git
| developers for it, exactly. No one should have to
| understand the internals of the system to use it well,
| though; that is a simple failure of software design.
| Moreover, even those internals do not particularly cohere.
| The index, the number of things labeled "-ish" in the
| glossary, the way that a "detached HEAD" interacts with
| branches, the distinction between tags and branches, the
| important distinctions between commits, refs, and
| objects... It is not that any one of those things is bad in
| isolation, but as a set they do not amount to a mental
| model I can describe charitably. Put in programming
| language terms: One of the reasons the "surface syntax" of
| Git is so hard is that its semantics are a bit confused,
| and that inevitably shows up in the interface to users.
| digdugdirk wrote:
| 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 wrote:
| 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 wrote:
| 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!
| cube2222 wrote:
| 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/
|
| [1]: https://kubamartin.com/posts/introduction-to-the-jujutsu-
| vcs...
| CharlieDigital wrote:
| This one is probably the _best_ intro I 've read:
| 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).
| stouset wrote:
| 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".
| hk1337 wrote:
| 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 wrote:
| 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.
| fragmede wrote:
| 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.
| nickandbro wrote:
| Kinda reminds me of https://ohmygit.org/
| CLiED wrote:
| 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 wrote:
| 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 wrote:
| Which GUI?
| ryeguy_24 wrote:
| 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 wrote:
| 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.
| mrkeen wrote:
| It's just the realities of participating in a distributed
| system. There's no 'current state' or 'now'.
|
| You could make the mental model easier to understand by
| centralising the state and switch to pessimistic locking
| instead of optimistic. But then you'd have to live with the
| downsides of those, like git's predecessors.
| SJC_Hacker wrote:
| There's definitely a local "current state". Its just that
| there's no inherent concept of a central repository or source
| of truth.
|
| In practice most people use it as if it does - the remote is
| "preferred". Which isn't such a bad thing if you know how to
| use branches and resolve conflicts properly.
|
| Best practice is to create a new branch for each feature,
| then create a PR into the proper branch.
|
| Early on in development it can be very chaotic as so much
| code is changing so quickly. No revision system is going make
| up for a lack of communication and division of
| responsibilities.
| subpixel wrote:
| 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.
| janosch_123 wrote:
| 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/
|
| 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 wrote:
| 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 wrote:
| 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
| Fuzzwah wrote:
| Was it https://vim-adventures.com ?
| janosch_123 wrote:
| Yes!!
| fsloth wrote:
| 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 wrote:
| 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 wrote:
| 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.
| absoluteunit1 wrote:
| 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 wrote:
| Sort of repeating a nested comment, but - I've been using fossil
| ( 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.
| jpat wrote:
| Neat game. You might want to check out this other git teaching
| game - https://learngitbranching.js.org/
| osigurdson wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sweezyjeezy wrote:
| I actually think git is a bad example of "just memorise these
| commands" - unless you are working with projects with a small
| number of users / branches - or you're fine to just delete and
| reclone if things get really hairy. I think a lot of my
| struggles with git came down to not grokking what it was
| actually DOING at first. Examples:
|
| - not understanding branch pointers / staging / committing
| corrently. E.g. [add file] [modify file again] [commit] - what
| just happened? (IMO these things could have been named better).
| Also reset vs revert vs restore - easier to use these if you've
| internalised branch pointers etc
|
| - git pull fails because it says it would overwrite a file
| you've never heard of - how is that file on your local? Is it
| ok to delete it?
|
| - times when you (or your colleagues) need to rewrite history
| (rebase / squashing etc) - require a pretty good mental model
| of what is going on to both diagnose issues and to fix them
| suzzer99 wrote:
| If you work at a place that doesn't care about a curated
| history, which I always have, it becomes much simpler.
| yodsanklai wrote:
| It's hard not to get stuck at some point if you don't have some
| understanding of the internals.
|
| If I was a beginner, I'll try to get some proficiency early on
| rather than having to learn the hard way when you're on the
| middle of a project. It's a good investment.
|
| I've also found that learning crafting nice commits made me a
| better programmer. It seemed difficult at first but now it's
| second nature (and I assume that in most teams, one is expected
| to submit small and self-contained commits anyway).
| -__---____-ZXyw wrote:
| 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/
|
| But perhaps they'd a good reason to go the route they did. Very
| interesting concept, anyway.
___________________________________________________________________
(page generated 2025-03-02 23:00 UTC)