6 ms·

> Git is hard: messing up is easy, and figuring out how to fix your mistakes is impossible. Hyperbolic. Fixing mistakes is easy if you understand the underlyi

> Git is hard: messing up is easy, and figuring out how to fix your mistakes is impossible. Hyperbolic. Fixing mistakes is easy if you understand the underlying data structure. Once you can conceptual map the structure into the intended form, you figure out what operations (verbs) you need. Then it’s a matter of mapping the operations into concrete command lines.

darkstar999 4y ago
"Rocket science is easy once you understand the underlying principles of rocket science"
- unicornmama 4y ago
  It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation.
  - ironmagma 4y ago
    Perhaps it is that they actually are curious, but the amount of knowledge to be had is quite substantial.
    - seba_dos1 4y ago
      I don't think that's the case with git though? It's fairly simple actually. The biggest (only?) challenge is to not view it as a tool to do versioning of your code, but rather a tool to work on data structures that effectively do versioning of your code. It seemed fairly straight-forward to me once I did that mental shift.
      - ironmagma 4y ago
        Everyone says that, but I don’t find it to be true. For context, we run a Gitea fork at work, and I often have to read the source code inherited from upstream Gitea. There are a ton of things that can happen during a merge, for example. Does anyone know what a smudge filter actually is? Why are there branches, and also tracking branches? There are refs, heads, objects, and blobs, and not all of those have the same operations (list, show) defined on them. There are changesets but also snapshots. Why do some commands have a --porcelain flag and others don’t? Did you know Git has garbage collection? You can’t rename a file in Git. What’s the difference between branches and tags? These are all things that are really discovered only through relentless trial and error.
        seba_dos1 4y ago
        I never dug into git tooling, I'm a mere git user - yet I knew most (not all) of these. Some of those actually make intuitive sense. And some of those don't really matter in regular usage, since it's not the actual on-disk data structure you need to be concerned about when working with git, but only parts of it that actually create the useful abstraction. Everyone seems to be learning git by staging and committing some code, then making pushes and pulls, with all the rest added on top of that. Basically, learning the UI first and only then figuring out what that UI actually does. I'd rather advice to start by learning what refs are and how commits actually look like on a imagined repository graph, since that (along with the working tree) is what you're actually manipulating most of the time - all the rest flows quite naturally from that. Merges and rebases are quite simple from that point of view, and the way heads, branches and tags work make perfect sense then. Objects and blobs can mostly be perceived as implementation details, but once you realize that there are no actual changesets in git at all, they quickly stop being obscure as well (and then the fact there's no such thing as file rename becomes obvious too). And when it comes to garbage collection, git lets you know that by itself on a big enough repo ;) When you start learning the UI already equipped with that knowledge, it simply makes much more sense. Git's biggest sin is not having a clear separation between the abstraction it presents to the user and what's essentially its internal implementation. It's like an UI made for people who not only work with git, but also on git. The result is poor UX, which is why you need to learn what git does first before learning its UI. But poor UX doesn't mean it's rocket science - it only means that you'll have a better time learning from an external resource. Clean and smudge filters seem interesting, I wasn't aware of them, thanks for mentioning that!
        everybodyknows 4y ago
        > You can’t rename a file in Git. $ git-mv <old_name> <new_name>
        ironmagma 4y ago
        That will produce an add plus a deletion. Whether or not this is considered a rename is up to git-diff, via the -M flag which specifies a “similarity index”. Side note, this doesn’t work with LFS-tracked files. But, with regular files you can say, e.g. you want the similarity index to be 50%, and then any files that were deleted that match 50% of their contents with another add will be displayed as a rename. So it’s really just a view thing. In the underlying storage, there is no such thing as a rename.
  - bdangubic 4y ago
    your heart is in the right place but for many engineers there are ~20 tools that we use daily and we pick tools in most cases specifically based on "do they work" and "do I need PhD to get them to work" if I need to know how the tool works that that tool has already failed miserably!
  - apeace 4y ago
    Are you amazed that the people who use the software you build use it without understanding the underlying data model? Probably not, because you understand that the reason you make software for them is so they can use it, instead of manually doing all the underlying steps your program does for them. Just because a tool is intended for engineers doesn’t mean it isn’t “hard” if it requires way more learning than any other tool in that engineer’s tool chain. Git is hard, even if you happen to have mastered it by now.
  - throw0101a 4y ago
    > It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation. And how many of them use word processors and/or spreadsheets and don't bother learning about the internal structures of file formats? * https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats Have you ever examined the bitstream of gzip or the structure of tar, even if you downloaded source file in them? Do you know the structure of RPM and/or Deb packages (depending on your favourite distro)? Do you know the voltage pattern of the Ethernet signals that go down the cable (or waveform of the Wifi / LTE radio signal)? There are only so many hours in the day, and not everyone wants to (or has the time) to go deep into every rabbit hole.
    - unicornmama 4y ago
      Consider that there’s a simple heuristic to prioritize where you drill down. That heuristic is pain.
- sam_bristow 4y ago
  One of my current projects at $DAYJOB is teaching literal rocket scientists how to use git effectively.
  - unicornmama 4y ago
    This deserves its own hackernews thread :)
hangonhn 4y ago
So that’s exactly my problem and I’ve yet to come across a guide that explains the underlying concept well. Any recommendations? I often feel like I’m uttering spells without understanding it when I use git. I hate working like that. Thanks in advance!
- mynameismon 4y ago
  I've recommended it here previously, and I'll do it again, because it's so fantastic: Missing Semester's lecture on Git https://www.youtube.com/watch?v=2sjqTHE0zok https://www.youtube.com/watch?v=2sjqTHE0zok
- sray 4y ago
  The Git book does a perfectly good job of this: https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 I always recommended reading chapters 1-3 and skimming chapter 7 to people who are just getting started with Git.
- cratermoon 4y ago
  Git for ages 4 and up. https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4
- unicornmama 4y ago
  I asked myself what goes inside a commit, how git structures [e.g. connects different commits] together, why can't I tamper a commit, why are git histories tamper proof; I asked questions about what happens to the structures when I performed daily operations [fetch, merge, checkout, push -f etc.]. When I wasn't understanding merge conflicts I taught myself what git tries to do and contemplated over why you need three-way merge [e.g. instead of two way]. Some of this I was able to figure out about thinking through the problem, considering alternatives and some had to be done through reading. My approach to learning is not so much "bottom up" [e.g. I can't just read a book from chapter 1, or some website that claims to explain everything].
- everybodyknows 4y ago
  Have a ready toolkit of general-purpose state-dumping "spells" ready at hand, to apply as soon as your tree starts to misbehave. Starter set: $ git-status $ git-log --graph --oneline --all [--reflog] $ git-branch -avv $ git-config --list
phailhaus 4y ago
> Once you can conceptual map the structure into the intended form This is the problem. A tool that hides its internal structure but requires you to rebuild it in your head is poorly designed, full stop. The reason git is difficult to deal with is that it is a low level abstraction over the underlying data structure, but simultaneously hides that complexity until suddenly you need to be aware of all of it.
throw0101a 4y ago
> Fixing mistakes is easy if you understand the underlying data structure. Once you can conceptual map the structure into the intended form, you figure out what operations (verbs) you need. Cue the old joke: > git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217

darkstar999 4y ago

"Rocket science is easy once you understand the underlying principles of rocket science"

unicornmama 4y ago
It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation.
- ironmagma 4y ago
  Perhaps it is that they actually are curious, but the amount of knowledge to be had is quite substantial.
  - seba_dos1 4y ago
    I don't think that's the case with git though? It's fairly simple actually. The biggest (only?) challenge is to not view it as a tool to do versioning of your code, but rather a tool to work on data structures that effectively do versioning of your code. It seemed fairly straight-forward to me once I did that mental shift.
    - ironmagma 4y ago
      Everyone says that, but I don’t find it to be true. For context, we run a Gitea fork at work, and I often have to read the source code inherited from upstream Gitea. There are a ton of things that can happen during a merge, for example. Does anyone know what a smudge filter actually is? Why are there branches, and also tracking branches? There are refs, heads, objects, and blobs, and not all of those have the same operations (list, show) defined on them. There are changesets but also snapshots. Why do some commands have a --porcelain flag and others don’t? Did you know Git has garbage collection? You can’t rename a file in Git. What’s the difference between branches and tags? These are all things that are really discovered only through relentless trial and error.
      - seba_dos1 4y ago
        I never dug into git tooling, I'm a mere git user - yet I knew most (not all) of these. Some of those actually make intuitive sense. And some of those don't really matter in regular usage, since it's not the actual on-disk data structure you need to be concerned about when working with git, but only parts of it that actually create the useful abstraction. Everyone seems to be learning git by staging and committing some code, then making pushes and pulls, with all the rest added on top of that. Basically, learning the UI first and only then figuring out what that UI actually does. I'd rather advice to start by learning what refs are and how commits actually look like on a imagined repository graph, since that (along with the working tree) is what you're actually manipulating most of the time - all the rest flows quite naturally from that. Merges and rebases are quite simple from that point of view, and the way heads, branches and tags work make perfect sense then. Objects and blobs can mostly be perceived as implementation details, but once you realize that there are no actual changesets in git at all, they quickly stop being obscure as well (and then the fact there's no such thing as file rename becomes obvious too). And when it comes to garbage collection, git lets you know that by itself on a big enough repo ;) When you start learning the UI already equipped with that knowledge, it simply makes much more sense. Git's biggest sin is not having a clear separation between the abstraction it presents to the user and what's essentially its internal implementation. It's like an UI made for people who not only work with git, but also on git. The result is poor UX, which is why you need to learn what git does first before learning its UI. But poor UX doesn't mean it's rocket science - it only means that you'll have a better time learning from an external resource. Clean and smudge filters seem interesting, I wasn't aware of them, thanks for mentioning that!
      - everybodyknows 4y ago
        > You can’t rename a file in Git. $ git-mv <old_name> <new_name>
        ironmagma 4y ago
        That will produce an add plus a deletion. Whether or not this is considered a rename is up to git-diff, via the -M flag which specifies a “similarity index”. Side note, this doesn’t work with LFS-tracked files. But, with regular files you can say, e.g. you want the similarity index to be 50%, and then any files that were deleted that match 50% of their contents with another add will be displayed as a rename. So it’s really just a view thing. In the underlying storage, there is no such thing as a rename.
- bdangubic 4y ago
  your heart is in the right place but for many engineers there are ~20 tools that we use daily and we pick tools in most cases specifically based on "do they work" and "do I need PhD to get them to work" if I need to know how the tool works that that tool has already failed miserably!
- apeace 4y ago
  Are you amazed that the people who use the software you build use it without understanding the underlying data model? Probably not, because you understand that the reason you make software for them is so they can use it, instead of manually doing all the underlying steps your program does for them. Just because a tool is intended for engineers doesn’t mean it isn’t “hard” if it requires way more learning than any other tool in that engineer’s tool chain. Git is hard, even if you happen to have mastered it by now.
- throw0101a 4y ago
  > It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation. And how many of them use word processors and/or spreadsheets and don't bother learning about the internal structures of file formats? * https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats Have you ever examined the bitstream of gzip or the structure of tar, even if you downloaded source file in them? Do you know the structure of RPM and/or Deb packages (depending on your favourite distro)? Do you know the voltage pattern of the Ethernet signals that go down the cable (or waveform of the Wifi / LTE radio signal)? There are only so many hours in the day, and not everyone wants to (or has the time) to go deep into every rabbit hole.
  - unicornmama 4y ago
    Consider that there’s a simple heuristic to prioritize where you drill down. That heuristic is pain.
sam_bristow 4y ago
One of my current projects at $DAYJOB is teaching literal rocket scientists how to use git effectively.
- unicornmama 4y ago
  This deserves its own hackernews thread :)

hangonhn 4y ago

So that’s exactly my problem and I’ve yet to come across a guide that explains the underlying concept well. Any recommendations? I often feel like I’m uttering spells without understanding it when I use git. I hate working like that. Thanks in advance!

mynameismon 4y ago
I've recommended it here previously, and I'll do it again, because it's so fantastic: Missing Semester's lecture on Git https://www.youtube.com/watch?v=2sjqTHE0zok https://www.youtube.com/watch?v=2sjqTHE0zok
sray 4y ago
The Git book does a perfectly good job of this: https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 I always recommended reading chapters 1-3 and skimming chapter 7 to people who are just getting started with Git.
cratermoon 4y ago
Git for ages 4 and up. https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4
unicornmama 4y ago
I asked myself what goes inside a commit, how git structures [e.g. connects different commits] together, why can't I tamper a commit, why are git histories tamper proof; I asked questions about what happens to the structures when I performed daily operations [fetch, merge, checkout, push -f etc.]. When I wasn't understanding merge conflicts I taught myself what git tries to do and contemplated over why you need three-way merge [e.g. instead of two way]. Some of this I was able to figure out about thinking through the problem, considering alternatives and some had to be done through reading. My approach to learning is not so much "bottom up" [e.g. I can't just read a book from chapter 1, or some website that claims to explain everything].
everybodyknows 4y ago
Have a ready toolkit of general-purpose state-dumping "spells" ready at hand, to apply as soon as your tree starts to misbehave. Starter set: $ git-status $ git-log --graph --oneline --all [--reflog] $ git-branch -avv $ git-config --list

phailhaus 4y ago

> Once you can conceptual map the structure into the intended form This is the problem. A tool that hides its internal structure but requires you to rebuild it in your head is poorly designed, full stop. The reason git is difficult to deal with is that it is a low level abstraction over the underlying data structure, but simultaneously hides that complexity until suddenly you need to be aware of all of it.

throw0101a 4y ago

> Fixing mistakes is easy if you understand the underlying data structure. Once you can conceptual map the structure into the intended form, you figure out what operations (verbs) you need. Cue the old joke: > git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217