5 ms·
>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 pre
by 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 agoUsing 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 agoBut 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.
- wruza 7y agoPlain text is internally ropes-something, indented with meters of vimscript, colored with a syntax model that is okay to change, hard to create from scratch, etc. it’s all hidden from a regular user who uses a subset of all features. But if you ignore the non-ms movement, shortcuts and advanced transforms, it is still a text editor that everyone may use. You can’t put your text (text, not a current mode!) into a state that looks okay but requires a vim guru to continue or start over because something is broken in the model. That’s different from git issues where working copy looks okay, but the branch and merge are broken in subtle ways. >Plain text is just a lot simpler than a VCS repository. Than a Git repository, not a VCS one. Not saying that VCS = plain text, but much simpler models exist for merging teh codes.
- kragen 7y ago> 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.
- oblio 7y ago> 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)
- kragen 7y agoThe latter! Sorry, didn't mean to cause you to question your sanity.
- hurrrrrrrr 7y agoOn the other hand I understand de data model of git and can't to the most basic shit without looking up which invocation I need via search engine/man pages. Like... deleting a branch `git branch -d` (-D for forced deletion). Deleting a remote? `git remote rm`. Knowing the model teaches me nothing about the ui.
- war1025 7y agoThis seems like a good opportunity to plug two aliases I wrote about a year ago that have been very helpful for cleaning up all the extraneous branches that would show up when I ran `git branch`. I run `git listdead` after I merge and delete a branch and do the next fetch (`git pull --rebase`). That lists the branches that can now be deleted. Then I run `git prunedead` and it actually removes them. Previously if I ran `git branch` it would list every development branch I had ever created in nearly a decade of work. Now it lists maybe ten branches. listdead = "!sh -c \"git branch -vv | grep ': gone]' | awk '{print \\$1}'\"" prunedead = "!sh -c \"git branch -vv | grep ': gone]' | awk '{print \\$1}' | xargs git branch -D\""