12 ms·

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned

• viraptor 7y ago
  > I feel like people learn git the wrong way Why do you think it's the wrong way? I sit somewhere in between and think that some people want to know the details and learning from inside is a good idea. But some other people want to simply be users and for the tool to get out of their way - and that's also good. So if the docs or the UX make either way hard or less effective, that's on the docs or the UX to improve.
  • ddevault 7y ago
    You'll use git a hundred times a day, every day, for the rest of your career. It's easily worth the hour it'll take to learn it properly.
    • im3w1l 7y ago
      It's not a given you will use it for the rest of your career. As two examples, neither Google nor Facebook use git.
      • cweagans 7y ago
        shrug I'm probably never going to work at either of those places. For pretty much everywhere else, Git works just fine. Maybe if I play my cards right, I'll use git for the rest of my career. If not, maybe there will be something new eventually, but I imagine that the concepts learned in mastering Git would still be useful.
        • democracy 7y ago
          many places were fine with cvs and svn as well
          • cweagans 7y ago
            Was anyone _really_ fine with cvs?
        • jschwartzi 7y ago
          You should give Mercurial a try. When you enable the changeset editing extensions it does everything Git does and is much easier to use and understand. I’ve trained people on both systems and Mercurial is much less creaky. The only reason everyone uses Git is for historical reasons because most of the modules In referring to weren’t added to Mercurial until like 09 when Git started seeing widespread use.
          • cweagans 7y ago
            I used mercurial quite a bit back in 2010. It's nice, but I don't see the value in sinking a bunch of time into it these days. Every one of the projects that I interact with regularly are in a Git repo on some kind of Git hosting service and the projects are run by people who understand/use Git regularly. For those projects, switching to Mercurial is a net loss, even just considering the time it takes to migrate the codebase + related processes (think CI, issue queue integration, even the repo hosting itself). Sure, I could use hg-git, but that doesn't gain me much either: now I'm the guy with the weird setup. If something goes wrong with my setup, it's too weird for other people to help with. If something goes wrong with somebody else's setup, I'm not that helpful because I have a weird setup.
    • viraptor 7y ago
      Sure, but I also use a mouse. I could learn how the optical mouse works. I have some guesses about it too, but never actually learned the details. But I'm a user of it - it works even if I don't understand exactly how and nobody tells me that I learned using the mouse "the wrong way" because of it.
      • ddevault 7y ago
        A typical mouse has 2-3 buttons, a wheel, and an X/Y axis. Git is 100x more complex, if not more. Give me a break. I'm sick of people glamorizing the idea that you should have your hand held through each step of every tool you use and never expend any effort on becoming an expert in the tools of your trade. Git is an engineering tool, designed by and for professionals. Imagine this kind of obscene complatency in other fields.
        • viraptor 7y ago
          I meant the tool-vs-internals idea, not the specific example here. If you want something comparable in complexity: we learn programming from `print "hello world"`, not from memory models and assembly. Some people even just start with `=sum(...)` in excel. Every programmer pretty much stops at the level that's useful and productive for them. There's often sentiment that people should know more, but I don't think I've ever seen anyone saying starting programming from high level is "the wrong way". Example from out of it: doctors learn both how to use USG and how it works. But in every case, I've seen it in that order: practice, then internals.
          • ddevault 7y ago
            >we learn programming from `print "hello world"`, not from memory models and assembly You're talking to the wrong crowd with me, you know. I disagree with this approach, too. Maybe we start with "hello world" to get a taste, but the first thing we should do is start breaking it down.
            • viraptor 7y ago
    • deleted 7y ago
      [deleted]
    • RJIb8RBYxzAMX9u 7y ago
      I'm not certain that git will be the dominant VCS forever, as I'd used CVS, Perforce, Subversion, Mercurial, in various degrees when they were dominant (or at least relevant). Who knows, maybe Linus will have another epiphany, while Microsoft somehow mismanages GitHub and squanders all the goodwill away. Then, a group of upstarts... That said, wanting to learn git's internals for the sake of knowledge is fine as motivation.
      • 101404 7y ago
        Then there's Gitlab and a few others.
        • jefurii 7y ago
          Also sourcehut / sr.ht.
      • Vinnl 7y ago
        Even if it stays at widely used as it is now for just two more years it'd already be worth the hour of effort.
  • masklinn 7y ago
    > Why do you think it's the wrong way? Because the porcelain is a nonsensical pile of crap on it’s own so you really can not make sense of it from the top down, it actively resist that approach. That’s not an assertion that it’s a good thing mind, just that it’s the only one: learning git from the bottom up is much easier than top-down, and people who dislike that approach are simply hosed.
• zbobet2012 7y ago
  I view not learning the basic concepts of how git works inside like trying to learn SQL without know what a table is. You could, but its easier if understand that basic abstractions which are its fundamental building blocks.
  • hombre_fatal 7y ago
    I think it's more like learning enough SQL to build an application without learning about indexes and transactions: you can be sufficiently productive until you encounter corner cases or things go wrong.
  • bfung 7y ago
    Theoretically, a person could learn SQL by knowing relational algebra and still not know what a table is. Just sayin’.
  • masklinn 7y ago
    > I view not learning the basic concepts of how git works inside like trying to learn SQL without know what a table is. That’s complete nonsense. A table is not a low level implementation detail of sql it’s a core feature. And I don’t have to known how tables are represented on disk or what they store exactly to acquire a good intuition of how things work. SQL is in and of itself an abstraction decoupled from the underlying concerns of implementation and execution. Something git’s porcelain definitely is not.
• agumonkey 7y ago
  funny how these same words came to many https://codewords.recurse.com/issues/two/git-from-the-inside-out https://codewords.recurse.com/issues/two/git-from-the-inside...
• cs702 7y ago
  Love the name -- very fitting. > I said that the internals were so simple that you could implement a workable version... inside of an afternoon. So I wrapped up what I was working on and set out to prove it. Been there. Done that. With other things, not git. I suspect many others here have too. > Five hours later, it had turned into less of a simple explanation of "look how simple these primitives are, we can create them with only a dozen lines of shell scripting!" and more into "oh fuck, I didn't realize that ...". Then it became a personal challenge to try and make it work anyway... Yep. Been there too. Done that too. Again, with other things, not git. I suspect many others here have too.
• juped 7y ago
  Why even have the index? Just skip that step.
  • ddevault 7y ago
    I wanted to have the staging area, and I had decided upfront that I wouldn't make the repository state inconsistent between shit and git. So the index needed to be done. Also, you need to generate a tree out of something. Could just hash the entire worktree every time, but that would be pretty lame.
    • deathanatos 7y ago
      What I never fully understood is why the staging area isn't simply a commit that gets amended repeatedly as files are staged into it. Maybe just a tree pointer, since the rest of the commit data isn't available until commit, but you could fill in some placeholders. ("(staging)" for the message, current times for the timestamps, etc.) (Note that index doubles for other functions like merging/conflict resolution, but I never thought that was a good thing, and could be separated out.)
      • smichel17 7y ago
        I've wanted this for a long time, and also a frequently-amended working-tree-as-a-commit. Why? I prefer a each branch to have its own staging area and working tree, which maps better to my mental model of "branch as an under-development feature". Currently my workflow to achieve this involves a lot of stashing.
        • rswail 7y ago
          What's the difference between a stash and a "working tree as a commit"?
        • _ikke_ 7y ago
          Do you know about git worktree? Because that sounds exactly what you want. Each worktree has its own index (staging area) and working tree.
• chx 7y ago
  > the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. Agreed. I always said the best git tutorial is https://www.sbf5.com/~cduan/technical/git/ https://www.sbf5.com/~cduan/technical/git/ > The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
  • na85 7y ago
    >The conclusion I draw from this is that you can only really use Git if you understand how Git works. I say this as someone who uses git regularly, and who prefers it to all other version control systems I have tried: A tool that breaks the principle of encapsulation by forcing you to grok its internals if you are to have any hope of understanding its arcane and inconsistent usage syntax is frankly not a very good tool. By contrast, I don't understand how vim works beyond the base conceptual level (keypress goes in, character shows up on screen or command is executed) and yet I don't have any trouble using it. I don't need to know vim's internals to use it effectively. Vim is a good tool.
    • anoncake 7y ago
      Using Vim requires you to understand how the data it operates on is structured. The same applies to Git. Plain text is just a lot simpler than a VCS repository.
      • IcePic 7y ago
        But you can use your awesome vim skill to feed text into a OpenOffice document, and while the OOo internals are probably 100x more complicated than vim, the user interface for "text on my screen" stays the same, and transition is smooth, even though the internals underneath is vastly different. If git requires 'everyone' to know the internals before they can use it, as opposed to rcs,cvs,svn,perforce users who can more easily flip around between those for most basic usages, then its on git for having a complicated shell around a complicated set of internals. It would have been nice if there was a simpler shell around the complex machinery for those (us?) who don't want to do crazy stuff, who don't need to be able to do crazy stuff and who could settle for only the simple 90% of the tooling like we do with the alternatives, but are forced to use git for external reasons.
• wkjagt 7y ago
  > instead of the inside out Now the name makes even more sense. I first read it as sh/git, but reading it as something that starts inside and slowly works its way out is now my preferred explanation of the name.
  • orthoxerox 7y ago
    I am simultaneously revolted and fascinated with the brilliance of your explanation.
  • thih9 7y ago
    This comment looks like an offtopic pun to me and feels distracting.
    • deleted 7y ago
      [deleted]
  • sbergot 7y ago
    The name also plays well with the porcelain & plumbing metaphores of git.
    • hyperpallium 7y ago
      metaphors. Not being pedantic, it just puzzled me a while to see what was wrong with that word.
      • fouc 7y ago
        what do you get when you cross a metaphor and a semaphore? a metaphore
        • majewsky 7y ago
          So it's a metaphor that only a limited amount of people can use at any given time?
        • 7y ago
• ssivark 7y ago
  > oh fuck, I didn't realize that the git index is a binary file format I wonder if the project (or likely, another one) might be better served by implementing the index using plain text (or whatever else might be more natural for shell wrangling) to elucidate the conceptual structure rather than matching git literally. PS: The name is very apropos. One doesn’t see too many such fitting opportunities — feels warm and fuzzy to see this one well used :-)
• aasasd 7y ago
  Git internals are fine. Now, if the utils gave access to human-oriented operations with those internals without the user googling every time they need something not-yet-memorized, that would be splendid. As it is, the utils are already pretty shitty without a reimplementation.
• peterwwillis 7y ago
  Still more sane than JavaScript to me. Would use this over a 500MB Node.js implementation.
  • efreak 7y ago
    Is this a reference to something? I can't imagine it would take 500mb to reimplement git in JavaScript. This one's <75kb and full of explanations: https://github.com/maryrosecook/gitlet https://github.com/maryrosecook/gitlet
    • GordonS 7y ago
      It's a dig at the typical size of a `node_modules` folder. These often are very large, and often do contain several thousand files, largely due to transitive dependencies.
  • thcz 7y ago
    For anyone looking to use Git in JS, check out https://github.com/isomorphic-git/isomorphic-git https://github.com/isomorphic-git/isomorphic-git. I've had great success with it and really like it as a library. It's API design is good and it's tree-shakeable so the size of the library is very reasonable, even if taking it as a whole.
• Hello71 7y ago
  eh, common.sh is a lot more complicated than it could be. example: write_hex() { hex="$1" echo "$hex" | sed -e 's/../&\n/' | while read -r hexbyte; do printf "\\x$hexbyte" done } you can imagine other shenanigans with xargs or something, but I think this strikes the best balance between performance and readability (as far as shell script goes). read_int16 and read_int32 don't work on big-endian systems, or if int is 16 bits instead of 32. the latter issue can be easily fixed by explicitly specifying -td2/-td4, but the former issue is not so easy. I think it requires either figuring out the endianness beforehand, or better, something like this: od -An -tx1 -j"$offs" -N4 "$path" | while read a b c d; do echo $(((0x$a << 24) | (0x$b << 16) | (0x$c << 8) | 0x$d)) done oddly, this is used in ls-files already. and yes, I checked: 0x$a is POSIX, and the arithmetic evaluation size must be at least a signed long, which is at least 32 bits. 'for x in $y; do printf "$a%s$b" "$x"; done' is equivalent to 'printf "$a%s$b" $y' (assuming neither a nor b contain format specifiers). similarly, 'for i in {1..100}; do printf "$a"; done' is equivalent to 'printf "$a%s.0" {1..100}'. unfortunately, brace expansion is not POSIX, but these are both significantly more efficient (both in code size and execution time) than the loop methods. sha1sum is not POSIX. I think shell arithmetic provides you enough tools to implement https://en.wikipedia.org/wiki/SHA-1#SHA-1_pseudocode https://en.wikipedia.org/wiki/SHA-1#SHA-1_pseudocode directly, although it may be slightly slower than a C implementation. awk is probably faster than shell.
  • acqq 7y ago
    Such a long text... to end with arguing non-POSIX solution. But the initial goal of the project was having a POSIX code, and it can indeed be a valid goal. So the whole post is "a lot more complicated than it could be." Tl dr: you wouldn't make POSIX code.
    • Hello71 7y ago
      what the fuck? I specified POSIX alternatives to non-POSIX uses in the code. only one feature, brace expansion, is not POSIX, so I specifically did not recommend its use.
      • 7y ago
• kakakiki 7y ago
  Couldn't resist looking at it after your repeated warnings. It seems that shellcheck site has some suggestions to improve the code.
• whalesalad 7y ago
  Even with the self deprecating nature of this effort and project: you continue to produce a lot of open source contributions. I see your work and blog all over the place. You’re a machine! So what’s your secret?
• 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.
• aequitas 7y ago
  Would you say if the data format was say JSON, YAML or TOML or any more human and bash friendly format it would have been easy to implement with your current experience? Not to vouch for having Git store things in human format. But I often think about how inefficient JSON API's and YAML storage formats are (in parse time) just to be a benefit of a user debugging it or discovering the API through a browser. But since most people use a JSON prettifier plugin or a tool like Postman anyways, what is the benefit of the line format being character strings? Wouldn't a binary package not be just as easy translatable into human readable JSON formatted output as a compacted JSON string is?
  • Sean1708 7y ago
    > what is the benefit of the line format being character strings? Wouldn't a binary package not be just as easy translatable into human readable JSON formatted output as a compacted JSON string is? One benefit is that I can look at an arbitrary file/response and be able to tell with a fairly high certainty whether it's JSON, YAML, or TOML, but there's no way that I tell whether it's messagepack, bson, or protobufs.
    • aequitas 7y ago
      Most of the time you know the format you expect to decode you don't have to guess it anyway. But I think you should be able to detect the type of format for binary encodings just as well as there spec is pretty specific. Maybe not at glance as a human, but that is the point I'm making. Should all line formats be made absolute human readable and parsable at glance just to the benefit of debugging at the cost of performance. Where with just a simple lens tool you can look at the data in a completely different (human friendly) view. Tools like this already exist in the form of WireShark, only they mostly operate at a deeper level.
• jasode 7y ago
  >I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git commands (the "porcelain"). Yes, I know that git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file format of BLOBs and SHAs, etc. If I were to implement a DVCS, I would inevitably end up reinventing many of the same technical architecture decisions that Linus came up with. But none of that insider knowledge really helps me remember git syntax if I haven't been using it in more than a month. Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes https://stackoverflow.com/questions/tagged/git?tab=Votes The git UI and unintuitive syntax is just too hard for me to remember unless I use it every day. In contrast... In vi or MS Word, I can effectively modify text without digging into underlying "rope data structure"[1]. In databases & SQL, I can "INSERT INTO x" without learning the "internals" of b-trees[2]. In Photoshop, I can stack layers without learning the math "plumbing" of alpha blending[3]. And yet for some reason, Git in particular needs people to learn it "inside out" more so than other tools. Not sure why Git needs this cognitive prerequisite. [1] https://en.wikipedia.org/wiki/Rope_(data_structure) https://en.wikipedia.org/wiki/Rope_(data_structure) [2] https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databases https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databas... [3] https://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blending https://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blendi...
  • cormacrelf 7y ago
    Unfortunately, I think you have to learn this way because everyone who came before you also did. So not only is the porcelain oriented towards this understanding, but so are people's existing repositories and workflows. People regularly use the limited subset of git that Github permits without learning how it works internally. If only the 'edit this file' button were powerful enough to do actual work... It isn't, and that's the other problem: internals knowledge actually helps you do day-to-day versioning tasks. The reality is that one day two developers will submit PRs that conflict, and you'll have to find a way to merge them both, and knowing how rebasing works inside absolutely helps you. The analogy is more MSWord style-stacking than manipulating ropes directly, because Git does manage to completely hide some of its guts. (Object storage, compression, transfer come to mind.)
• AsyncAwait 7y ago
  For anyone wanting to understand Git from inside out at a fundamental level, I can't recommend the 'Building Git' book enough. The code is Ruby, but there's enough explanation for each snippet to be able to follow along in whatever language one prefers. I had no problems with translating to Go, for example. 1 - https://shop.jcoglan.com/building-git https://shop.jcoglan.com/building-git
• globular-toast 7y ago
  Indeed, I've come to the same conclusions myself. I'm the resident git expert at my job but, quite honestly, the only thing that separates me is that I've learnt git's internals. But I learnt it because I'm lazy and it's easier, not because I want to be the best or anything. So many people say they "know" git, but then I watch them work and it's "git commit -a" all the time and "git clone" when something doesn't look right. It's really amazing how people refuse to learn this essential tool.
• Iwan-Zotow 7y ago
  You know that Linus wrote first version of git in mostly bash, right?