191–200 of 235 posts
Earlier quoted context omitted.
> I don't understand how vim works beyond the base conceptual level How much time have you spent trying to figure out how to change the font size in Vim, rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it? If the answer is “none”, you probably have a pretty deep understanding of the data model Vim manipulates, even if you aren't aware of it.
> rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it I'm not sure if I'm missing some features in Vim or you're actually pulling my leg by forcing me to notice that I know more about text than I care to admin :-) (I'm not OP, BTW, just a random passer-by)
Earlier quoted context omitted.
>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 to…
> I don't understand how vim works beyond the base conceptual level How much time have you spent trying to figure out how to change the font size in Vim, rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it? If the answer is “none”, you probably have a pretty deep understanding of the data model Vim manipulates, even if you aren't aware of it.
Earlier quoted context omitted.
I really disagree, a small amount of customisation of tools can reap significant productivity gains. I think your anecdote is really just an example of bad management, not bad tooling. Could easily be that some management doofus had prohibited git from being installed on the 'production' system.
I think the problem is the idea of 'tooling'. A table saw by itself is mostly useless. With a fence and a miter gauge, it becomes useful. With a push block, stop block, subfence, outfeed table, infeed table, featherboard, crosscut sled, tenon jig, and dado set, it is the single most useful tool in a woodshop. Keep in mind it is still one tool and all those accessories are not "tooling", they are accessories to a sing…
Early contender for Best Analogy 2020.
Earlier quoted context omitted.
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 moti…
Then there's Gitlab and a few others.
Amusing, but less than the title suggests (no porcelain, no reliability properties, no error checking, etc). Still, fun stuff.
Why would you expect reliability and error checking in a shell implementation of git? It's clearly a mad bit of fun.
I completely require it in shell scripts in general. Good checking of errors is really a fundamental requirement of professional programming.
Earlier quoted context omitted.
> 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 prob…
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".
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.