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.
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.
I'm not sure I entirely agree with this. I could see how this could be the case for newcomers to git, but after learning how git works through visual means, I think the mental model of how one should think of git is pretty simple (pleasantly simple, imo). Any complexity that comes from it may be due to how it is used (especially in a team setting).
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".
Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary.
Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again…
The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
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.
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.
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
This is like saying "I've lived in a house for 15 years and I've never had a problem. I don't understand how people could have a problem living in a house." The thing is, living in a house isn't a very specific experience. The difficulty of the problems you might face varies a lot by many factors.
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.
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).
Same here - I've been using it for a long time without any real deep understanding of it and still no issues. I _do_ believe that there's a "hidden" layer of collaborative functionality that I'm missing out on, but since everybody I work with uses git the same way I do, I suspect that if I did know what I was missing out on, I'd just be frustrated that I wasn't able to take advantage of it.
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).
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”.
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.
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.
Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.
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
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.
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.
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.
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.
This is simply what happens when you pay people with very little knowledge large amounts of money to do something that requires expertise. I'm not sure why we're pussyfooting around that.
It would be like not knowing about loops or how to print text to the screen or how to do I/O. People seem to think you can be clueless and somehow still deserve a programmer's salary. The entitlement baffles me (and I've experienced a lot of it from people throughout my career).
A staff SWE who can't send you a patch is simply unworthy of their title, the way I'm unworthy of the title "pilot" or "doctor" or "attorney".
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
The only winning move is to learn your tools and develop a mental model of what they're doing. You know, like everything else a programmer needs to know.
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.
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.
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,
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 :)
I'm sorry, but it's been ten years and you haven't learned how to handle other git situation? And then you're dependent on Google? Is there a reason why you haven't sat down to learn some more?
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.
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?
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.
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!
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.
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.
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.
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
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.
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.
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.
mjburgess|1 year ago
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.
nlawalker|1 year ago
https://www.gnu.org/fun/jokes/ed-msg.html
quickslowdown|1 year ago
I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
Tijdreiziger|1 year ago
[1] https://git-scm.com/book/en/v2
asungy|1 year ago
I'm not sure I entirely agree with this. I could see how this could be the case for newcomers to git, but after learning how git works through visual means, I think the mental model of how one should think of git is pretty simple (pleasantly simple, imo). Any complexity that comes from it may be due to how it is used (especially in a team setting).
rectang|1 year ago
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`:
[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...
BobbyTables2|1 year ago
Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary.
Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again…
The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
SketchySeaBeast|1 year ago
philipwhiuk|1 year ago
TheBigSalad|1 year ago
ghfhghg|1 year ago
osigurdson|1 year ago
sweezyjeezy|1 year ago
- 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
getnormality|1 year ago
Vaslo|1 year ago
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.
yodsanklai|1 year ago
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).
commandlinefan|1 year ago
Same here - I've been using it for a long time without any real deep understanding of it and still no issues. I _do_ believe that there's a "hidden" layer of collaborative functionality that I'm missing out on, but since everybody I work with uses git the same way I do, I suspect that if I did know what I was missing out on, I'd just be frustrated that I wasn't able to take advantage of it.
m3kw9|1 year ago
cube2222|1 year ago
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|1 year ago
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|1 year ago
subpixel|1 year ago
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|1 year ago
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.
oniony|1 year ago
Once you're done with the tutorial bit, the https://learngitbranching.js.org/?NODEMO version is good to try out commands and see what the tree looks like after each command.
initialcommit|1 year ago
syntaxing|1 year ago
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.
bloopernova|1 year ago
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.
graypegg|1 year ago
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.
initialcommit|1 year ago
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.
starsixtynine|1 year ago
It would be like not knowing about loops or how to print text to the screen or how to do I/O. People seem to think you can be clueless and somehow still deserve a programmer's salary. The entitlement baffles me (and I've experienced a lot of it from people throughout my career).
A staff SWE who can't send you a patch is simply unworthy of their title, the way I'm unworthy of the title "pilot" or "doctor" or "attorney".
rochacon|1 year ago
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
yodsanklai|1 year ago
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.
BurningFrog|1 year ago
That handles 98% of what I need to do. For the remainder I sometimes stumble pretty badly, but figure things out.
adastra22|1 year ago
WolfeReader|1 year ago
mths|1 year ago
whoateallthepy|1 year ago
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.
pxmpxm|1 year ago
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.
initialcommit|1 year ago
nottoohard|1 year ago
[deleted]
ryeguy_24|1 year ago
112233|1 year ago
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|1 year ago
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.
nottoohard|1 year ago
[deleted]
fsloth|1 year ago
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.
__loam|1 year ago
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.
loloquwowndueo|1 year ago
ptx|1 year ago
nottoohard|1 year ago
[deleted]
janosch_123|1 year ago
+ 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.
Fuzzwah|1 year ago
gunian|1 year ago
bloomingkales|1 year ago
never_inline|1 year ago
* 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.
Shacklz|1 year ago
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.
initialcommit|1 year ago
nottoohard|1 year ago
jpat|1 year ago
initialcommit|1 year ago
CLiED|1 year ago
rectang|1 year ago
metabagel|1 year ago
QuadrupleA|1 year ago
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|1 year ago
[deleted]
ctxcode|1 year ago
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|1 year ago
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.
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. 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,
For a combo add-everything+commitinitialcommit|1 year ago
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 :)
john-tells-all|1 year ago
"commit all files and add a comment" = `cam`, "also push" = `camp`
> cam "fixed bug"
alias cam='git commit -am'
function camp() { git commit -am "$1" git push }
starsixtynine|1 year ago
pestatije|1 year ago
Nzen|1 year ago
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.
Etheryte|1 year ago
01HNNWZ0MV43FF|1 year ago
mopsi|1 year ago
starsixtynine|1 year ago
fHr|1 year ago
digdugdirk|1 year ago
QuadrupleA|1 year ago
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!
graypegg|1 year ago
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.
lqet|1 year ago
[0] https://www.oreilly.com/library/view/version-control-with/97...
commandersaki|1 year ago
fragmede|1 year ago
-__---____-ZXyw|1 year ago
But perhaps they'd a good reason to go the route they did. Very interesting concept, anyway.
initialcommit|1 year ago
nickandbro|1 year ago
initialcommit|1 year ago
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.
absoluteunit1|1 year ago
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.
hk1337|1 year ago
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|1 year ago
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.
ranscendental50|1 year ago
There was nothing stressful about it : ))
fragmede|1 year ago
tvb12|1 year ago
initialcommit|1 year ago
mlhpdx|1 year ago
fragmede|1 year ago
gacmachine1|1 year ago
pixelpoet|1 year ago
27theo|1 year ago
...
initialcommit|1 year ago
fHr|1 year ago
bigstrat2003|1 year ago
_flux|1 year ago
rho4|1 year ago
HNSupportsUA|1 year ago
[deleted]