4 ms·

If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool.

by blub 7y ago

If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Having to learn about the internals is a giveaway that the tool suffers from poor encapsulation. To me git is definitely one of those tools where one should satisfice and not learn it deeply, because it's not worth the effort. One can successfully stick to a simple workflow and ignore anything git astronauts come up with, like git flow if they want to keep their sanity and focus on what matters - creating quality software. And almost any team has some git fetishist which will be thrilled to help when things go south. And if they don't, it's probably for the better.

TeMPOraL 7y ago
> If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Not necessarily. This may mean (and I think in this case, it does) that people are too afraid to learn about those "internals" - or should I say, the mental model behind the tool (and then some of those people write tutorials for others, perpetuating the problem). And with a "monkey see, monkey do" approach, people can fail at anything, up to and including tying their own shoelaces. There is no such thing as a perfect encapsulation. Not in programming, and especially not in the physical world. "Internals" are ever-present and leak into view all the time. A good abstraction is just one that you can use day-to-day without constantly minding what's going on behind the scenes. More importantly though, when you're just learning a bunch of git commands in isolation ("monkey see, monkey do"), you're not learning a tool/an abstraction - you're just learning its interface. That's sometimes OK, but in general, for effective use of an abstraction it's better to learn what moving pieces it is abstracting away. Which in case of Git is that it's a DAG. DAGs are kind of fundamental in programming, too; it's good to understand them.
- xmodem 7y ago
  > There is no such thing as a perfect encapsulation. It's a logical fallacy to use this as an excuse for a tool having bad encapsulation/abstraction. Yes it's impossible to have a perfect abstraction. No that doesn't mean we shouldn't try harder.
- navaati 7y ago
  Completely agree. > Which in case of Git is that it's a DAG And one step beyond that, that it's a Merkel tree. It's key to understanding stuff like "if I change a commit, it changes all commit after that" or "if I move (cherry pick, rebase) this commit, I'm creating a new one, not really moving".
  - ilammy 7y ago
    > And one step beyond that, that it's a Merkel tree. Not really, not every block chain is a Merkle tree. Since Git history is not linear, you can’t order the commits in any canonical way. You definitely can order them in some way (like "git log" does) and then construct a tree for that list of hashes, but this is not really useful computation. Git repo integrity is verified simply by HEAD commit hash because you normally clone the entire repository anyway.
    - TeMPOraL 7y ago
      Is git even a Merkle tree? Git history forms a DAG, not a tree. But I'm not 100% sure about how the hashes are computed - whether they work on the DAG, or on some local subtree.
      - ilammy 7y ago
        No, it’s not. Commit hashes are exactly what it says on the tin: hash sums of commit objects, which are basically text files that include hash sums of tree objects (directory tree state), hash sums of parent commits, your commit message and other metadata. You can see it with "git cat-file": $ git cat-file -p d8defd0bb0062ed541de173a2aec834b64d6adbe tree cbdb56fe9bb1766d8fc2b2e53c9c934efbacbf1c parent a8a1049c06d100a3f926a82414e6addb9b9af5e8 author ilammy <alexei@cossacklabs.com> 1581533224 +0200 committer ilammy <alexei@cossacklabs.com> 1581533224 +0200 fixup! Avoid unsigned overflow in length computations And compute the commit hash manually to verify that: $ sha=d8defd0bb0062ed541de173a2aec834b64d6adbe $ cat <(echo -ne "$(git cat-file -t $sha) $(git cat-file -s $sha)\0") \ <(git cat-file -p $sha) | sha1sum d8defd0bb0062ed541de173a2aec834b64d6adbe - Git prefixes object content with object type ("commit" in case of commits), its size in bytes (textual, decimal), terminated by a null byte. And hashes all of that get the commit hash.
- JoeAltmaier 7y ago
  Its part of a bigger issue - source control tools have wildly different fundamental models. Moving to git from anything else will be confusing, because users jump to conclusion about what commands and operations are doing. Its different from other tools in important ways.
  - huherto 7y ago
    I moved from SCCS to RCS to CVS to Subversion to Git. Moving to Git was the more difficult step for me. I prefer it now. For a while I had to move back to Subversion and I hated it.
    - touisteur 7y ago
      Can't use svn for the life of me, though I used it for 10 years before trying git for a real dvcs need (remote team for a while)... Just the idea pains me. Missing git add -p, cherry-pick & rebase -i so much I immediately put git-svn on if I have to go back... Also, it makes telecommuting easier, asynchronous team work so much simpler... I think the key 'abstraction' that people don't understand is cherry-pick. I can't explain clearly in fine details /how/ it works, but it is the base of so much of git's power...
- blub 7y ago
  Monkey see, monkey do would be watching someone use git and imitating them. Reading the manual or an overview of the commands and using them is how learning new tools typically works. It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools and then move on with our professional lives, which likely revolve around writing software and not fumbling with git. By the way, I love your conversation about Merkle trees below; it was one of the most surreal things I've read lately. :-)
  - TeMPOraL 7y ago
    > It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools The problem revolves around the fact that, despite same name being used, git!branch != svn!branch, git!commit != svn!commit, etc. They serve related purposes - but not the same, because the concepts behind them are different. Learning a tool means learning those concepts. So in the process of learning "git commit" and "git branch", you're supposed to pick up on the "pointer to a node in a DAG" thing - otherwise you haven't learned "git commit", you've learned something else that's vaguely similar. And then you'll have difficulties when its behavior goes against your expectations.
    - blub 7y ago
      But they behave pretty darn close to SVN branches and commits and... they're also called branches and commits. It's clear why that happened - no one would have used a weird tool which turned the old concepts on their heads, so git was being taught based on comparisons with existing tools. Now that git's very popular, the teachers have become arrogant and are claiming that our mental models for how VCS work are wrong and we should instead adapt our thinking to the git internals. In almost all other professions a confusing tool is scorned, but only developers are expected to learn how all sorts of weird contraptions work and then anyone who can't keep up is scorned instead. git is almost 15 years old and here we have yet another attempt at clarifying how it works to the masses. Why are there so many git GUIs and tutorials and attempts to clarify how this tool works? It's a freaking VCS, not rocket science. git took something that used to be straightforward and doable by any developer and turned it into an over-complicated mess. Now here's a question for you: why do you defend this anti-developer tool instead of siding with fellow developers?
2zcon 7y ago
>that's a pretty obvious hint that there's something wrong with the tool. Or that the problem space is inherently difficult.
wyclif 7y ago
Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this: Coworker: "I really hate Git, it's so hard to understand what's going on internally." Git guy: "Did you read the documentation?" Coworker: "Nope." Git guy: "Did you read Git - book?" Coworker: "Nope." Git guy: "Did you read Scott Chacon's 'Pro Git'?" Coworker: "Nope." Git guy: "..."
- Ace17 7y ago
  The likelihood for this conversation to occur, in a way, also depends on the tool itself, and tells us something about it. As a matter of fact, git is hard to use. The question is: keeping the same level of functionality, could it have been made easy to use?
  - p_l 7y ago
    It also speaks about the quality of users as a whole - we somehow forgot to RTFM at all or lead people to documentations, simultaneously accepting lack of documentation in a vicious cycle.
  - amenod 7y ago
    And the answer is: yes, absolutely. Mercurial is a whole level better. Unfortunately git won - because of GitHub, not on technical merit.
- blub 7y ago
  That conversation already went off the tracks at "internally", since it shouldn't matter at all how it works internally. We do not learn how most things work in detail, because we wouldn't have time to live our life if we did. In this particular case, git is a version control tool and it supports various typical operations for such tools. One should be able to learn the commands and then successfully use the tool. If that's not possible, I continue to assert that there's a problem with the tool.

by blub 7y ago

TeMPOraL 7y ago

> If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Not necessarily. This may mean (and I think in this case, it does) that people are too afraid to learn about those "internals" - or should I say, the mental model behind the tool (and then some of those people write tutorials for others, perpetuating the problem). And with a "monkey see, monkey do" approach, people can fail at anything, up to and including tying their own shoelaces. There is no such thing as a perfect encapsulation. Not in programming, and especially not in the physical world. "Internals" are ever-present and leak into view all the time. A good abstraction is just one that you can use day-to-day without constantly minding what's going on behind the scenes. More importantly though, when you're just learning a bunch of git commands in isolation ("monkey see, monkey do"), you're not learning a tool/an abstraction - you're just learning its interface. That's sometimes OK, but in general, for effective use of an abstraction it's better to learn what moving pieces it is abstracting away. Which in case of Git is that it's a DAG. DAGs are kind of fundamental in programming, too; it's good to understand them.

xmodem 7y ago
> There is no such thing as a perfect encapsulation. It's a logical fallacy to use this as an excuse for a tool having bad encapsulation/abstraction. Yes it's impossible to have a perfect abstraction. No that doesn't mean we shouldn't try harder.
navaati 7y ago
Completely agree. > Which in case of Git is that it's a DAG And one step beyond that, that it's a Merkel tree. It's key to understanding stuff like "if I change a commit, it changes all commit after that" or "if I move (cherry pick, rebase) this commit, I'm creating a new one, not really moving".
- ilammy 7y ago
  > And one step beyond that, that it's a Merkel tree. Not really, not every block chain is a Merkle tree. Since Git history is not linear, you can’t order the commits in any canonical way. You definitely can order them in some way (like "git log" does) and then construct a tree for that list of hashes, but this is not really useful computation. Git repo integrity is verified simply by HEAD commit hash because you normally clone the entire repository anyway.
  - TeMPOraL 7y ago
    Is git even a Merkle tree? Git history forms a DAG, not a tree. But I'm not 100% sure about how the hashes are computed - whether they work on the DAG, or on some local subtree.
    - ilammy 7y ago
      No, it’s not. Commit hashes are exactly what it says on the tin: hash sums of commit objects, which are basically text files that include hash sums of tree objects (directory tree state), hash sums of parent commits, your commit message and other metadata. You can see it with "git cat-file": $ git cat-file -p d8defd0bb0062ed541de173a2aec834b64d6adbe tree cbdb56fe9bb1766d8fc2b2e53c9c934efbacbf1c parent a8a1049c06d100a3f926a82414e6addb9b9af5e8 author ilammy <alexei@cossacklabs.com> 1581533224 +0200 committer ilammy <alexei@cossacklabs.com> 1581533224 +0200 fixup! Avoid unsigned overflow in length computations And compute the commit hash manually to verify that: $ sha=d8defd0bb0062ed541de173a2aec834b64d6adbe $ cat <(echo -ne "$(git cat-file -t $sha) $(git cat-file -s $sha)\0") \ <(git cat-file -p $sha) | sha1sum d8defd0bb0062ed541de173a2aec834b64d6adbe - Git prefixes object content with object type ("commit" in case of commits), its size in bytes (textual, decimal), terminated by a null byte. And hashes all of that get the commit hash.
JoeAltmaier 7y ago
Its part of a bigger issue - source control tools have wildly different fundamental models. Moving to git from anything else will be confusing, because users jump to conclusion about what commands and operations are doing. Its different from other tools in important ways.
- huherto 7y ago
  I moved from SCCS to RCS to CVS to Subversion to Git. Moving to Git was the more difficult step for me. I prefer it now. For a while I had to move back to Subversion and I hated it.
  - touisteur 7y ago
    Can't use svn for the life of me, though I used it for 10 years before trying git for a real dvcs need (remote team for a while)... Just the idea pains me. Missing git add -p, cherry-pick & rebase -i so much I immediately put git-svn on if I have to go back... Also, it makes telecommuting easier, asynchronous team work so much simpler... I think the key 'abstraction' that people don't understand is cherry-pick. I can't explain clearly in fine details /how/ it works, but it is the base of so much of git's power...
blub 7y ago
Monkey see, monkey do would be watching someone use git and imitating them. Reading the manual or an overview of the commands and using them is how learning new tools typically works. It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools and then move on with our professional lives, which likely revolve around writing software and not fumbling with git. By the way, I love your conversation about Merkle trees below; it was one of the most surreal things I've read lately. :-)
- TeMPOraL 7y ago
  > It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools The problem revolves around the fact that, despite same name being used, git!branch != svn!branch, git!commit != svn!commit, etc. They serve related purposes - but not the same, because the concepts behind them are different. Learning a tool means learning those concepts. So in the process of learning "git commit" and "git branch", you're supposed to pick up on the "pointer to a node in a DAG" thing - otherwise you haven't learned "git commit", you've learned something else that's vaguely similar. And then you'll have difficulties when its behavior goes against your expectations.
  - blub 7y ago
    But they behave pretty darn close to SVN branches and commits and... they're also called branches and commits. It's clear why that happened - no one would have used a weird tool which turned the old concepts on their heads, so git was being taught based on comparisons with existing tools. Now that git's very popular, the teachers have become arrogant and are claiming that our mental models for how VCS work are wrong and we should instead adapt our thinking to the git internals. In almost all other professions a confusing tool is scorned, but only developers are expected to learn how all sorts of weird contraptions work and then anyone who can't keep up is scorned instead. git is almost 15 years old and here we have yet another attempt at clarifying how it works to the masses. Why are there so many git GUIs and tutorials and attempts to clarify how this tool works? It's a freaking VCS, not rocket science. git took something that used to be straightforward and doable by any developer and turned it into an over-complicated mess. Now here's a question for you: why do you defend this anti-developer tool instead of siding with fellow developers?

2zcon 7y ago

>that's a pretty obvious hint that there's something wrong with the tool. Or that the problem space is inherently difficult.

wyclif 7y ago

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this: Coworker: "I really hate Git, it's so hard to understand what's going on internally." Git guy: "Did you read the documentation?" Coworker: "Nope." Git guy: "Did you read Git - book?" Coworker: "Nope." Git guy: "Did you read Scott Chacon's 'Pro Git'?" Coworker: "Nope." Git guy: "..."

Ace17 7y ago
The likelihood for this conversation to occur, in a way, also depends on the tool itself, and tells us something about it. As a matter of fact, git is hard to use. The question is: keeping the same level of functionality, could it have been made easy to use?
- p_l 7y ago
  It also speaks about the quality of users as a whole - we somehow forgot to RTFM at all or lead people to documentations, simultaneously accepting lack of documentation in a vicious cycle.
- amenod 7y ago
  And the answer is: yes, absolutely. Mercurial is a whole level better. Unfortunately git won - because of GitHub, not on technical merit.
blub 7y ago
That conversation already went off the tracks at "internally", since it shouldn't matter at all how it works internally. We do not learn how most things work in detail, because we wouldn't have time to live our life if we did. In this particular case, git is a version control tool and it supports various typical operations for such tools. One should be able to learn the commands and then successfully use the tool. If that's not possible, I continue to assert that there's a problem with the tool.