10 ms·
The day I got over what I feel was the end of the steep part of the learning curve, everything made so much sense. Everything became easy to do. I've never been
by mabbo 9y ago
The day I got over what I feel was the end of the steep part of the learning curve, everything made so much sense. Everything became easy to do. I've never been confused or unsure of what was going on in git since.
What git needs is a chair lift up that hill. A way to easily get people there. But I have no idea what that would look like. Lots of people try, few do very well at it.
- sammygutierrez 9y agoGit Pro's chapter on git internals does a good job of explaining some of the things going on under the hood. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
- johnfn 9y agoThe whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner workings, it's so clear" then it is by definition a poor abstraction.
- andrewflnr 9y agoWho said it's supposed to be an abstraction? The point, theoretically, of something like Git is that the actual unvarnished model is clear enough that you don't need an abstraction. The problem IMO is that the commands are kind of random and don't map cleanly to the model.
- AstralStorm 9y agoIndeed, the worst offenders are in my opinion checkout, reset and pull. They mix multiple only slightly related commands in one.
- simik 9y agoThere are couple projects that try to tackle this problem by providing an alternative CLI (on top of git's own plumbing), like gitless and g2. Haven't used any of them myself, but would be interested in experience of others.
- specialist 9y agoLeaky abstractions is how we get stuff like ORMs.
- pritambaral 9y agoTo be fair, most ORMs poorly implement the "leaky" principle. When implemented well, like with SQLAlchemy, the end result is a much nicer ORM. In fact, one of the things in common among the ORMs that have left a bad taste in my mouth is that they all tried to abstract away SQL without leaking enough of it.
- specialist 9y agoI have a different thesis: Picking the ideal interface to abstract is critically important (and very hard). In the case of ORMs, available solutions abstract the schema (tables, rows, fields), the objects, or use templates. My solution abstracted JDBC/ODBC. The only leak in my abstraction was missing metadata, which I was able to plug (with much effort!). My notions for interfaces, modularity, abstractions are mostly informed by the book "Design Rules: The Power of Modularity". http://a.co/hXOGJq1 http://a.co/hXOGJq1
- naasking 9y agoAny interface means you'll build an mental model of the system you're manipulating. How else could you possibly know what you want to do and what commands to issue? So given a mental model is inevitable, seems reasonable that that model should be the actual model.
- ethbro 9y ago> So given a mental model is inevitable, seems reasonable that that model should be the actual model. I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces.
- flukus 9y ago> I think the longevity of SQL has proved there's value is non-leaky abstracted interfaces. How is sql non-leaky? To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc. To debug and improve them you need to look at the query plan which is the database exposing it's inner workings to you. You have to know about the abstractions an sql server sits on as well. Why is it faster if it's on an SSD instead of an HDD? Why does the data dissapear if it's an in memory DB?
- bch 9y ago> To be proficient with sql you have to understand how results are stored on disk, how indexes work, how joins work, etc No, you don’t. As far as I know, the data is stored in discrete little boxes and indexes are a separate stack of sorted little boxes connected to the main boxes by spaghetti. This is the abstraction, it works, and I don’t need to know about btrees, blocksizes, how locks are implemented, or anything else to grok a database.
- boudin 9y agoI disagree with that. The point of an abstraction is to not having to know the implementation. Understanding the principles used behind will always lead to a much better use of your abstraction
- AlexCoventry 9y agoI'd also say an abstraction could be carrying its weight even if it only reduces the amount you have to think about the implementation details when using it.
- jimmy1 9y agoThis might sound a little out of touch, but am I the only one who doesn't think git is that hard? It is a collection of named pointers and a directed acyclic graph. The internals aren't really important once you have that concept down.
- banku_brougham 9y agoBut what about the deal breaker in the article: a way to follow the decendants of a commit.
- pdfernhout 9y agoTook a few seconds with a search engine on "git descendants of a commit": https://stackoverflow.com/questions/27960605/find-all-the-direct-descendants-of-a-given-commit#27962018 https://stackoverflow.com/questions/27960605/find-all-the-di... That said, I do feel some "porcelain" git commands are poorly named and operate inconsistently -- compared to the plumbing of the acyclic graph concepts which is good but limited.
- e12e 9y agoYou mean you didn't just read git's easy-to-follow, well-structured man pages or built-in help? /s Half the time, when I know what I want, I both keep forgetting git flags and sub-commands - and struggle to find them in the man pages. Like the fine: git diff --name-only # i list only the files that are changed. But I'm not --list-files.
- iliaznk 9y agoExactly, it was no longer mysterious for me after I had to prepare a written branching procedure for our team starting from how to branch off, commit, rebase to doing resets and working with reflog. While doing that I've thoroughly read the official docs, examined lots of examples, created a local repo with a couple of text files to test various commands. An then it became so clear and simple! Especially the reflog – so powerful! So, my advice is to try to write some instructions for yourself for all the common cases you might run into during your work. It will not only help you realise what you actually need from git, but also will serve as a good cheat-sheet.
- mikez302 9y agoThis looks like a good chair lift: http://gitless.com/ http://gitless.com/
- TomK32 9y agoLike `git help`? I has everything important grouped nicely and hints you to even more subcommands.
- zwischenzug 9y agoI wrote a book that tries to :) https://leanpub.com/learngitthehardway https://leanpub.com/learngitthehardway I start with simple examples and work up from there. It's based on training I've conducted at various companies, and avoids talk of Merkle trees or DAG.