21 ms·

This looks promising as a teaching aide. At my previous company, I transitioned our project from Clearcase to Git to save us licensing and administration fees.

by lumb63 4y ago

This looks promising as a teaching aide. At my previous company, I transitioned our project from Clearcase to Git to save us licensing and administration fees. Many of the senior developers, who had never used Git, had a hard time understanding it, and I spent many whiteboard sessions explaining by drawing similar graphs. This would give those developers more autonomy, and stop the “let me blow it away and start over”, which would drive me nuts. Devs spent a lot of time and frustration performing that operation. I believe the core issue is devs like above never take the time to “grok” Git. I believe part of this is due to the lack of a tool like above to teach easily, but also because devs want to ignore the “how” of their tool working to find out the exact commands they need to run in their current situation. One could argue users should not need to understand how their tool works to use it effectively and this is a leaky abstraction. Others could argue some commands are not intuitive (git reset can do many things, and git rebase swapping ours/theirs comes to mind). I don’t claim Git is perfect, and sometimes I need to Google to learn more than I wanted to, to get out of an obscure scenario (e.g. someone put classified intelligence into a repository we need to transfer to a lower classification network; how do I rewrite the entire history while correcting this error that occurred 487 commits ago?). However, understanding the tree structure of Git, what git rebase does under the covers, what branches and tags are, how remotes work, how merging works, etc. would go a LONG way. The folk I worked with struggled to pick it up.

capableweb 4y ago
> I believe the core issue is devs like above never take the time to “grok” Git I believe the same, and it's not just a problem you see with git, it's all over the place. Some developers seems eager to use something so they just skim the documentation in order to do the least amount of reading and understanding in order to implement something, but often miss some fundamental detail and have to jump back. Or, they fundamentally misunderstand the tool at all, but push forward with their own idea what the tool is, rather than stepping back and start learning again.
- wpietri 4y ago
  You say that like it's bad, but that's just life. We're trying to fit a whole universe into 3 pounds of meat. If we stopped to truly understand anything before taking action, we'd never get anywhere. That's especially true in technology, where whole armies of people are working to complicate things as fast as possible. For the best of reasons, of course. But when I started out, I could read one short book and have a pretty good understanding of my computer's processor, and from there it wasn't much further to understanding the whole computer. Now I could spend days just understanding, say, processor cache strategies [1]. A field that is super interesting, but if I am to get any of my actual work done, I can't afford to dig into that and the many, many other similar subtopics. I'm going to get a casual understanding of something, do my best to make something useful, and only dig in further when I'm forced to. When I do have to dig in, it comes in two cases for me. One is where there is something necessary complexity that I would have to learn about regardless. E.g., if something is too slow, I need to learn about what happens under the hood to do proper performance tuning. Great, fine, I will learn it. But then there's the other bucket, which includes unnecessary complexity, bad abstractions, poorly considered UX, and the like. For me, git is clearly in that bucket. I intentionally have very simple development flows. Git can do a great deal, 98% of which I not only don't need, I actively don't want. [2] So I'm going do my best to remain ignorant of its inner workings, stick with my small number of commands, and very occasionally refer to "Oh Shit, Git!?!" [3] And I'm perfectly happy with that until it gets replaced with a technology that better matches the domain. [1] e.g.: https://chipsandcheese.com/2022/05/21/igpu-cache-setups-compared-including-m1/ https://chipsandcheese.com/2022/05/21/igpu-cache-setups-comp... [2] An example of what I don't want: https://www.tiktok.com/t/ZTRpPPuKf/ https://www.tiktok.com/t/ZTRpPPuKf/ [3] https://ohshitgit.com/ https://ohshitgit.com/
- pdimitar 4y ago
  I'm very happy to fundamentally misunderstand GIT's internals because I want to do a finite (and small) set of operations with it, not HOW it operates under the covers. Conflating the two, like you do, is elitism. "If you just stopped and read to understand...", a-ha, sure, I'll do that for every one of the no less than 500 tools I've used over the course of my career and will never get anything done on time. There's no time. We got real work to do and no we can't switch to a company that gives us this time. There's a big world outside the Silicon Valley. GIT is a huge UX failure and seeing people pretend otherwise makes me question my -- or their -- sanity.
  - counttheforks 4y ago
    [flagged]
    - pdimitar 4y ago
      The only one complaining here is you. Also this is not Reddit, chill.
      - counttheforks 4y ago
        You can either learn the tools of the trade, or you can go online and complain about how your hammer is too hard to use and so you refuse to hold it right. How is that not complaining?
        maccard 4y ago
        That's not a good analogy. A better analogy is someone telling you that you need to understand material sciences to be able to use an impact driver properly.
        counttheforks 4y ago
        Can you learn material sciences in an afternoon of minimal effort?
- counttheforks 4y ago
  It's insane to me how many developers simply refuse to read documentation or spend any time at all learning the new tools they're supposed to use.
  - howinteresting 4y ago
    This is all Stockholm syndrome. Git has a lot of random accidental complexity, from reset and checkout doing too many things (yes I'm aware of switch and restore), to stacks being a pain to work with. The idea that you're supposed to just be in the middle of an interactive rebase most of the time is mind-boggling. A better thing to say is "yeah we've been saddled with this horrible tool, yeah we know it sucks, but it'll suck a bit less when you learn it. Oh and sorry if you're not a professional developer and have to use git, I hope we can do better next time."
    - counttheforks 4y ago
      Yes, we all know it has some rough edges and could be more convenient. Unless someone actually makes that idyllic more convenient tool and it becomes widespread, none of that matters. We're stuck with the hammer that everyone else is using. No sense refusing to learn how to use it just because you're stubborn, everyone else managed just fine.
      - bornfreddy 4y ago
        Well no, that's not the case. In fact many projects (gitless for example) clearly show that a consistent UI for git is possible, but unless git developers decide to rework the tool completely, we are stuck with what we have. And no, using a 3rd party tool and convincing every team that gitless is better is simply not going to happen. The way out is for someone to swallow their pride, admit they did a half-assed job and fix it. Not holding my breath though. I say that as someone who uses git daily, who has learned git internals, who uses cli almost exclusively, who helps the teammates out of their git problems and who still hates the cli inconsistencies.
  - charlie0 4y ago
- lumb63 4y ago
  I've seen this phenomenon as well. I've noticed a few factors that I hypothesize contribute to this: 1) Making Computer Science programs in universities overly simple. When I was in college, I tutored students in CS. When I started college, the CS 101 course was taught in Java, and when I finished, it was being taught in Python. There was an immense gap between the understanding of the Python-first vs. Java-first students. The Java-first students understood fundamental concepts like arrays, passing parameters by reference vs. by value, "OOP" concepts, and other common paradigms in languages. The Python-first students would use "lists" and "dictionaries" for many problems without understanding that those structures impacted the time complexity of their solutions, or that they used memory allocation, reallocation, hashing, etc. Python is great for hacking together a non-fault-tolerant program that does X as quickly as possible, but I saw it damage the way the students thought about computing. It made the students think it ought to be easy. It made them think that they should be able to write, in nearly plain English, what they wanted the computer to do, and that it ought to do it. It made them think they should be able to intuitively be able to code without spending any amount of time learning the craft, and that they could do anything an advanced programmer could do by typing a few lines of simple code. They were less willing to accept that sometimes problems are hard, sometimes they would have to think, and sometimes they would have to write more than a for loop to solve problems. The Java students' problem sets covered implementation of data structures and complex applications, while the Python students struggled to put together even the implementation. For a humorous and broader explanation of this subject, see James Mickens' excellent article The Night Watch [0]. For example: "That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge." 2) Bad documentation, and bad users of documentation. I dislike documentation that neglects how the tool works and instead creates a cookbook that its users can copy verbatim. It has similar effects to what I described above. Developers that use this type of documentation find themselves helpless when they encounter a problem they've not memorized the solution to. I think it also creates a learned helplessness wherein users cannot question the model the tool uses or think outside that model to solve complex problems. I prefer documentation that teaches the ethos of the subject in question so that I can understand better and imagine new solutions. I've also heard the complaint that Git's documentation is awful; some say that it is only useful if you know already know where what you are looking for is, and useless if not. In other words, it lacks an "apropos" (aka "man -k") equivalent. This is my gripe with "wiki" style documentation. It is scattered and unsearchable and has no cohesion. We as developers need to do a better job creating documentation that is searchable, coherent, and useful to new and experienced users alike. Various sections of documentation should have ample cross-references to help users understand the connection between parts of the system to help them form a mental model of how tooling works. [0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf https://www.usenix.org/system/files/1311_05-08_mickens.pdf
initialcommit 4y ago
Yes much agree! A big reason I wanted to pursue this idea is exactly what you mentioned - a lack of ability to easily create presentation-quality Git structures that can apply specifically to the situation a user is in, NOW. A super annoying thing about troubleshooting Git issues is when you find a similar solution online but it's done in someone's random repo which could be very different that yours. Your whiteboard sessions are another good example down this line of thought.
NeutralForest 4y ago
Git is an amazing tool with terrible UX. It's very difficult to know what the right thing to do is and the mental model is a bit weird. For example, undoing an operation is another, new commit.
- eagle2com 4y ago
  That is the option of last resort, when you have already pushed _and_ you cannot mess with the history anymore. The other one being reseting your local branch to a previous commit and force pushing if needed. Edit: wording
IshKebab 4y ago
Were you trying to teach them with the CLI though? That's a terrible approach. The CLI is awful and Git is a visual thing. It's like teaching someone to drive a car using LOGO. The way to teach Git is: 1. Explain the mental model (correctly). Basically a commit is a snapshot with deduplication to avoid huge file sizes. 2. Show them how to use a good Git GUI. There are a lot of bad ones. I would recommend Git Extensions (terrible name but it's actually quite good). Or maybe GitX on Mac. 3. Let them learn the CLI slowly in their own time.
- lumb63 4y ago
  I never found a GUI that was more intuitive than the CLI, personally. I am a bad person to consult for this, since I live in vim and tmux (my coworkers hid my mouse for April Fool’s Day and I went the day without it to make a point) while others blaze ahead in VS Code and know the bare minimum command line to get their job done. I’ll take a look at Git Extensions, thanks for the recommendation! Some of our devs took to using the integration with VS Code, which I didn’t like because I didn’t understand how its terminology (e.g. “sync” mapped to underlying Git operations). Others tried the Git GUI which I found very confusing. I focused on the graphical operations and then tried to show them what commands they could run to execute those operations. Next time I’m in the situation, maybe I’ll adopt a GUI-first approach.
  - bornfreddy 4y ago
    My issue with gui is that sometimes I need to work with git in terminal, over ssh, so I need to know it. Once I learned it, what's the point of using a gui? [0] [0] there is one operation where gui is more convenient for me - exploring branches in gui or GitLab ("repository -> graph") has no equivalent in cli that I know of (interestingly, GitHub doesn't have that either, but many gui tools do).
    - IshKebab 4y ago
      > Once I learned it, what's the point of using a gui? The first point is that it makes it easier to learn the concept of Git, which is most of the difficulty. Yes Git's CLI is really terrible, but if you know the concepts you can mostly just google the CLI options and learn through repetition. The second point is that GUIs make it easier to see the state of the repo. There's a reason that even the CLI includes a basic GUI. Don't tell me you never use `git log --oneline --decorate=all --graph`.
philsnow 4y ago
> I believe the core issue is devs like above never take the time to “grok” Git. I believe part of this is due to the lack of a tool like above to teach easily, but also because devs want to ignore the “how” of their tool working to find out the exact commands they need to run in their current situation. Github is largely to "blame" for this. It mostly only exposes the happy path and using git kind of like any other VCS, but above all it ossifies the idea of git repositories being centralized (both because the canonical repo is always on github.com but also because of the forking/ownership model). A lot of the power (and sharp edges, and messiness) of git are in scenarios where everybody has a local repo and nobody's is really "canonical". Git is really well-suited to development of the linux kernel. It's not.. amazingly well-suited for the job that 95% of people these days press it into?
- dev_snd 4y ago
  I think that the bigger problem is the misuse of Tags as the sole method of marking a commit for release for example. Tags could be utilised for naming commits which would make it much easier to reason about where in the process of your development you are instead of referencing commits by hash. Hashes are hard to remember after all.
  - bornfreddy 4y ago
    Except, if you rebase, your tags get "lost" (not really, but they still point to the same old commit unless explicitly changed). Log is your friend, and making sure that the commits make sense (they do a single well-defined thing) helps a lot, because you always know which commit does what. But yes, that means using `git commit --fixup <commit id> && git -i --autosquash <commit id>^1` frequently to fix existing (older) commits instead of making new trivial ones.
    - airtonix 4y ago
      why are you rebasing a branch that has tags? in my opinion (the one where i don't care what anyone else thinks kind) you shouldn't be using tags on your working branches and your mainline/release branches should only be the ones where tags exists. This then means that the only place you should be rebasing is your working/feature/pr branches and that when you merge your working/feature/pr branch, it should get squashed into the target branch... No one cares about your fifty gazillion 'wip' commits.
andyjohnson0 4y ago
> I believe the core issue is devs like above never take the time to “grok” Git. The problem I have with git us that it's just too complicated. When I'm juggling project complexities and design complexities and implementation complexities, I frequently don't want to have to deal with git too. I understand how to stage and check in and squash, and branch and merge, and how to manage remotes. But last week I still managed to get a new repo into a state where I couldn't push local changes to github without doing a pull first, and I couldn't do a pull without (apparently) first updating the remote. I had a hard deadline and ended up deleting the repo and starting fresh. Nothing much was lost. I never had this trouble with tfs... Maybe I'm just not clever enough, but I've never come across a dev tool with as much surface complexity as git. (Not a git hater. Use it every day. Have had a personal github profile for a decade. Etc etc.)
- howinteresting 4y ago
  You're not alone. Git is an embarrassment to our profession.
  - SavageBeast 4y ago
    Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.
    - fortran77 4y ago
      It was painfully difficult to branch in subversion. And remember the agony of asking someone to check in a file so another developer can check it out?
      - capitainenemo 4y ago
        Branching was just a copy? What was so hard about that? As for check-out locks. you only had to ask them to do that if they'd requested a lock on the file which was not the default. I hope people weren't doing that too often at your workplace.
cdcarter 4y ago
My company is currently transitioning from a 20+ year old Perforce depot to a git workflow. We're certainly having issues like you describe, where people don't know (and don't care to learn) the mechanics of git. And I agree, git is the kind of tool where once you understand the primitives, you can quickly start making lateral leaps to solve problems. But I do think that there's room for a better mechanism for orchestrating "macros" or building other workflows on top of git. I know a lot of developers who'd love the ability to pretend they're using p4.
- lumb63 4y ago
  My company wanted to "script away" all the "pain" of using Git to make it equivalent to Clearcase. I think it's a smell. If you want to use Clearcase, use Clearcase. etc.
  - ziml77 4y ago
    I don't think that's necessarily a bad thing. Using scripts to change how devs interact with git is just putting a new porcelain on the plumbing.
    - gdprrrr 4y ago
      Except you now have a set of tools without proper documentation and no way of googlng issues. And chances are you created a new leaky abstraction.
renox 4y ago
Ahem, let's avoid the over-generalisation thanks! I learned git at 45yo after many years using ClearCase (even licensed as CC admin) and .. I really liked learning git, I do admit that it took me two full days of self study to start groking git but I wouldn't call it 'struggling'. Obviously it depends a lot of your background.. git is the 5th version controls I've used , while it is far from being perfect (submodules.. :-( ), it's my favourite.
hyperthesis 4y ago
More like a backed-up abstraction, simpler on the inside. Though that's only true of the core, with tags being additional decorations and renames inferred. The simple core delegates complexity. I think designing a nicer git UX is not easy. Even if we oversimplify commit to cp your working directory together with a path to the previous commit (to form a tree of "branches"), then the abstraction for operations like rebase to manipulate that tree is not quite intrinsically simple. BTW Tools can be used without proper understanding, like arithmetic without commuting, associating or distributing. While a workable pidgin aids adoption, it's fair to argue for the power of understanding, especially of something clean and coherent and whole. Git's core is like that; the add-ons (like tags) aren't; and the UX seems arbitrary and accreted.

by lumb63 4y ago

capableweb 4y ago

> I believe the core issue is devs like above never take the time to “grok” Git I believe the same, and it's not just a problem you see with git, it's all over the place. Some developers seems eager to use something so they just skim the documentation in order to do the least amount of reading and understanding in order to implement something, but often miss some fundamental detail and have to jump back. Or, they fundamentally misunderstand the tool at all, but push forward with their own idea what the tool is, rather than stepping back and start learning again.

wpietri 4y ago
You say that like it's bad, but that's just life. We're trying to fit a whole universe into 3 pounds of meat. If we stopped to truly understand anything before taking action, we'd never get anywhere. That's especially true in technology, where whole armies of people are working to complicate things as fast as possible. For the best of reasons, of course. But when I started out, I could read one short book and have a pretty good understanding of my computer's processor, and from there it wasn't much further to understanding the whole computer. Now I could spend days just understanding, say, processor cache strategies [1]. A field that is super interesting, but if I am to get any of my actual work done, I can't afford to dig into that and the many, many other similar subtopics. I'm going to get a casual understanding of something, do my best to make something useful, and only dig in further when I'm forced to. When I do have to dig in, it comes in two cases for me. One is where there is something necessary complexity that I would have to learn about regardless. E.g., if something is too slow, I need to learn about what happens under the hood to do proper performance tuning. Great, fine, I will learn it. But then there's the other bucket, which includes unnecessary complexity, bad abstractions, poorly considered UX, and the like. For me, git is clearly in that bucket. I intentionally have very simple development flows. Git can do a great deal, 98% of which I not only don't need, I actively don't want. [2] So I'm going do my best to remain ignorant of its inner workings, stick with my small number of commands, and very occasionally refer to "Oh Shit, Git!?!" [3] And I'm perfectly happy with that until it gets replaced with a technology that better matches the domain. [1] e.g.: https://chipsandcheese.com/2022/05/21/igpu-cache-setups-compared-including-m1/ https://chipsandcheese.com/2022/05/21/igpu-cache-setups-comp... [2] An example of what I don't want: https://www.tiktok.com/t/ZTRpPPuKf/ https://www.tiktok.com/t/ZTRpPPuKf/ [3] https://ohshitgit.com/ https://ohshitgit.com/
pdimitar 4y ago
I'm very happy to fundamentally misunderstand GIT's internals because I want to do a finite (and small) set of operations with it, not HOW it operates under the covers. Conflating the two, like you do, is elitism. "If you just stopped and read to understand...", a-ha, sure, I'll do that for every one of the no less than 500 tools I've used over the course of my career and will never get anything done on time. There's no time. We got real work to do and no we can't switch to a company that gives us this time. There's a big world outside the Silicon Valley. GIT is a huge UX failure and seeing people pretend otherwise makes me question my -- or their -- sanity.
- counttheforks 4y ago
  [flagged]
  - pdimitar 4y ago
    The only one complaining here is you. Also this is not Reddit, chill.
    - counttheforks 4y ago
      You can either learn the tools of the trade, or you can go online and complain about how your hammer is too hard to use and so you refuse to hold it right. How is that not complaining?
      - maccard 4y ago
        That's not a good analogy. A better analogy is someone telling you that you need to understand material sciences to be able to use an impact driver properly.
        counttheforks 4y ago
        Can you learn material sciences in an afternoon of minimal effort?
counttheforks 4y ago
It's insane to me how many developers simply refuse to read documentation or spend any time at all learning the new tools they're supposed to use.
- howinteresting 4y ago
  This is all Stockholm syndrome. Git has a lot of random accidental complexity, from reset and checkout doing too many things (yes I'm aware of switch and restore), to stacks being a pain to work with. The idea that you're supposed to just be in the middle of an interactive rebase most of the time is mind-boggling. A better thing to say is "yeah we've been saddled with this horrible tool, yeah we know it sucks, but it'll suck a bit less when you learn it. Oh and sorry if you're not a professional developer and have to use git, I hope we can do better next time."
  - counttheforks 4y ago
    Yes, we all know it has some rough edges and could be more convenient. Unless someone actually makes that idyllic more convenient tool and it becomes widespread, none of that matters. We're stuck with the hammer that everyone else is using. No sense refusing to learn how to use it just because you're stubborn, everyone else managed just fine.
    - bornfreddy 4y ago
      Well no, that's not the case. In fact many projects (gitless for example) clearly show that a consistent UI for git is possible, but unless git developers decide to rework the tool completely, we are stuck with what we have. And no, using a 3rd party tool and convincing every team that gitless is better is simply not going to happen. The way out is for someone to swallow their pride, admit they did a half-assed job and fix it. Not holding my breath though. I say that as someone who uses git daily, who has learned git internals, who uses cli almost exclusively, who helps the teammates out of their git problems and who still hates the cli inconsistencies.
- charlie0 4y ago
lumb63 4y ago
I've seen this phenomenon as well. I've noticed a few factors that I hypothesize contribute to this: 1) Making Computer Science programs in universities overly simple. When I was in college, I tutored students in CS. When I started college, the CS 101 course was taught in Java, and when I finished, it was being taught in Python. There was an immense gap between the understanding of the Python-first vs. Java-first students. The Java-first students understood fundamental concepts like arrays, passing parameters by reference vs. by value, "OOP" concepts, and other common paradigms in languages. The Python-first students would use "lists" and "dictionaries" for many problems without understanding that those structures impacted the time complexity of their solutions, or that they used memory allocation, reallocation, hashing, etc. Python is great for hacking together a non-fault-tolerant program that does X as quickly as possible, but I saw it damage the way the students thought about computing. It made the students think it ought to be easy. It made them think that they should be able to write, in nearly plain English, what they wanted the computer to do, and that it ought to do it. It made them think they should be able to intuitively be able to code without spending any amount of time learning the craft, and that they could do anything an advanced programmer could do by typing a few lines of simple code. They were less willing to accept that sometimes problems are hard, sometimes they would have to think, and sometimes they would have to write more than a for loop to solve problems. The Java students' problem sets covered implementation of data structures and complex applications, while the Python students struggled to put together even the implementation. For a humorous and broader explanation of this subject, see James Mickens' excellent article The Night Watch [0]. For example: "That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge." 2) Bad documentation, and bad users of documentation. I dislike documentation that neglects how the tool works and instead creates a cookbook that its users can copy verbatim. It has similar effects to what I described above. Developers that use this type of documentation find themselves helpless when they encounter a problem they've not memorized the solution to. I think it also creates a learned helplessness wherein users cannot question the model the tool uses or think outside that model to solve complex problems. I prefer documentation that teaches the ethos of the subject in question so that I can understand better and imagine new solutions. I've also heard the complaint that Git's documentation is awful; some say that it is only useful if you know already know where what you are looking for is, and useless if not. In other words, it lacks an "apropos" (aka "man -k") equivalent. This is my gripe with "wiki" style documentation. It is scattered and unsearchable and has no cohesion. We as developers need to do a better job creating documentation that is searchable, coherent, and useful to new and experienced users alike. Various sections of documentation should have ample cross-references to help users understand the connection between parts of the system to help them form a mental model of how tooling works. [0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf https://www.usenix.org/system/files/1311_05-08_mickens.pdf

initialcommit 4y ago

Yes much agree! A big reason I wanted to pursue this idea is exactly what you mentioned - a lack of ability to easily create presentation-quality Git structures that can apply specifically to the situation a user is in, NOW. A super annoying thing about troubleshooting Git issues is when you find a similar solution online but it's done in someone's random repo which could be very different that yours. Your whiteboard sessions are another good example down this line of thought.

NeutralForest 4y ago

Git is an amazing tool with terrible UX. It's very difficult to know what the right thing to do is and the mental model is a bit weird. For example, undoing an operation is another, new commit.

eagle2com 4y ago
That is the option of last resort, when you have already pushed _and_ you cannot mess with the history anymore. The other one being reseting your local branch to a previous commit and force pushing if needed. Edit: wording

IshKebab 4y ago

Were you trying to teach them with the CLI though? That's a terrible approach. The CLI is awful and Git is a visual thing. It's like teaching someone to drive a car using LOGO. The way to teach Git is: 1. Explain the mental model (correctly). Basically a commit is a snapshot with deduplication to avoid huge file sizes. 2. Show them how to use a good Git GUI. There are a lot of bad ones. I would recommend Git Extensions (terrible name but it's actually quite good). Or maybe GitX on Mac. 3. Let them learn the CLI slowly in their own time.

lumb63 4y ago
I never found a GUI that was more intuitive than the CLI, personally. I am a bad person to consult for this, since I live in vim and tmux (my coworkers hid my mouse for April Fool’s Day and I went the day without it to make a point) while others blaze ahead in VS Code and know the bare minimum command line to get their job done. I’ll take a look at Git Extensions, thanks for the recommendation! Some of our devs took to using the integration with VS Code, which I didn’t like because I didn’t understand how its terminology (e.g. “sync” mapped to underlying Git operations). Others tried the Git GUI which I found very confusing. I focused on the graphical operations and then tried to show them what commands they could run to execute those operations. Next time I’m in the situation, maybe I’ll adopt a GUI-first approach.
- bornfreddy 4y ago
  My issue with gui is that sometimes I need to work with git in terminal, over ssh, so I need to know it. Once I learned it, what's the point of using a gui? [0] [0] there is one operation where gui is more convenient for me - exploring branches in gui or GitLab ("repository -> graph") has no equivalent in cli that I know of (interestingly, GitHub doesn't have that either, but many gui tools do).
  - IshKebab 4y ago
    > Once I learned it, what's the point of using a gui? The first point is that it makes it easier to learn the concept of Git, which is most of the difficulty. Yes Git's CLI is really terrible, but if you know the concepts you can mostly just google the CLI options and learn through repetition. The second point is that GUIs make it easier to see the state of the repo. There's a reason that even the CLI includes a basic GUI. Don't tell me you never use `git log --oneline --decorate=all --graph`.

philsnow 4y ago

> I believe the core issue is devs like above never take the time to “grok” Git. I believe part of this is due to the lack of a tool like above to teach easily, but also because devs want to ignore the “how” of their tool working to find out the exact commands they need to run in their current situation. Github is largely to "blame" for this. It mostly only exposes the happy path and using git kind of like any other VCS, but above all it ossifies the idea of git repositories being centralized (both because the canonical repo is always on github.com but also because of the forking/ownership model). A lot of the power (and sharp edges, and messiness) of git are in scenarios where everybody has a local repo and nobody's is really "canonical". Git is really well-suited to development of the linux kernel. It's not.. amazingly well-suited for the job that 95% of people these days press it into?

dev_snd 4y ago
I think that the bigger problem is the misuse of Tags as the sole method of marking a commit for release for example. Tags could be utilised for naming commits which would make it much easier to reason about where in the process of your development you are instead of referencing commits by hash. Hashes are hard to remember after all.
- bornfreddy 4y ago
  Except, if you rebase, your tags get "lost" (not really, but they still point to the same old commit unless explicitly changed). Log is your friend, and making sure that the commits make sense (they do a single well-defined thing) helps a lot, because you always know which commit does what. But yes, that means using `git commit --fixup <commit id> && git -i --autosquash <commit id>^1` frequently to fix existing (older) commits instead of making new trivial ones.
  - airtonix 4y ago
    why are you rebasing a branch that has tags? in my opinion (the one where i don't care what anyone else thinks kind) you shouldn't be using tags on your working branches and your mainline/release branches should only be the ones where tags exists. This then means that the only place you should be rebasing is your working/feature/pr branches and that when you merge your working/feature/pr branch, it should get squashed into the target branch... No one cares about your fifty gazillion 'wip' commits.

andyjohnson0 4y ago

> I believe the core issue is devs like above never take the time to “grok” Git. The problem I have with git us that it's just too complicated. When I'm juggling project complexities and design complexities and implementation complexities, I frequently don't want to have to deal with git too. I understand how to stage and check in and squash, and branch and merge, and how to manage remotes. But last week I still managed to get a new repo into a state where I couldn't push local changes to github without doing a pull first, and I couldn't do a pull without (apparently) first updating the remote. I had a hard deadline and ended up deleting the repo and starting fresh. Nothing much was lost. I never had this trouble with tfs... Maybe I'm just not clever enough, but I've never come across a dev tool with as much surface complexity as git. (Not a git hater. Use it every day. Have had a personal github profile for a decade. Etc etc.)

howinteresting 4y ago
You're not alone. Git is an embarrassment to our profession.
- SavageBeast 4y ago
  Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.
  - fortran77 4y ago
    It was painfully difficult to branch in subversion. And remember the agony of asking someone to check in a file so another developer can check it out?
    - capitainenemo 4y ago
      Branching was just a copy? What was so hard about that? As for check-out locks. you only had to ask them to do that if they'd requested a lock on the file which was not the default. I hope people weren't doing that too often at your workplace.

cdcarter 4y ago

My company is currently transitioning from a 20+ year old Perforce depot to a git workflow. We're certainly having issues like you describe, where people don't know (and don't care to learn) the mechanics of git. And I agree, git is the kind of tool where once you understand the primitives, you can quickly start making lateral leaps to solve problems. But I do think that there's room for a better mechanism for orchestrating "macros" or building other workflows on top of git. I know a lot of developers who'd love the ability to pretend they're using p4.

lumb63 4y ago
My company wanted to "script away" all the "pain" of using Git to make it equivalent to Clearcase. I think it's a smell. If you want to use Clearcase, use Clearcase. etc.
- ziml77 4y ago
  I don't think that's necessarily a bad thing. Using scripts to change how devs interact with git is just putting a new porcelain on the plumbing.
  - gdprrrr 4y ago
    Except you now have a set of tools without proper documentation and no way of googlng issues. And chances are you created a new leaky abstraction.

renox 4y ago

Ahem, let's avoid the over-generalisation thanks! I learned git at 45yo after many years using ClearCase (even licensed as CC admin) and .. I really liked learning git, I do admit that it took me two full days of self study to start groking git but I wouldn't call it 'struggling'. Obviously it depends a lot of your background.. git is the 5th version controls I've used , while it is far from being perfect (submodules.. :-( ), it's my favourite.

hyperthesis 4y ago

More like a backed-up abstraction, simpler on the inside. Though that's only true of the core, with tags being additional decorations and renames inferred. The simple core delegates complexity. I think designing a nicer git UX is not easy. Even if we oversimplify commit to cp your working directory together with a path to the previous commit (to form a tree of "branches"), then the abstraction for operations like rebase to manipulate that tree is not quite intrinsically simple. BTW Tools can be used without proper understanding, like arithmetic without commuting, associating or distributing. While a workable pidgin aids adoption, it's fair to argue for the power of understanding, especially of something clean and coherent and whole. Git's core is like that; the add-ons (like tags) aren't; and the UX seems arbitrary and accreted.