3 ms·

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.
    - seba_dos1 4y ago
      See? That's what I was talking about. Learning the UI before learning what it actually does :) This only leads to confusion once you use 'git mv' and edit the file significantly enough in the same commit. "Why doesn't git show that it's a rename? I explicitly told it so! Did I do something wrong?"
      - ironmagma 4y ago
        The problem is, very few Git learning resources start off by introducing what refs are, objects, etc. and those that do are usually wrong in some way. There are really not enough learning resources to learn Git this way.

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.
  - seba_dos1 4y ago
    See? That's what I was talking about. Learning the UI before learning what it actually does :) This only leads to confusion once you use 'git mv' and edit the file significantly enough in the same commit. "Why doesn't git show that it's a rename? I explicitly told it so! Did I do something wrong?"
    - ironmagma 4y ago
      The problem is, very few Git learning resources start off by introducing what refs are, objects, etc. and those that do are usually wrong in some way. There are really not enough learning resources to learn Git this way.