10 ms·
Git for Computer Scientists (2010)
- throw0101a 5y agoI ran across this little gem recently: > Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * Isaac Wolkerstorfer, https://twitter.com/agnoster/status/44636629423497217 https://twitter.com/agnoster/status/44636629423497217
- beermonster 5y agoSee also this https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
- JJMcJ 5y agoReads like the man page for "git rebase".
- question000 5y agoRichard Feynman had a joke theory that any purely theoretical mathematical concept when expressed in layman's terms devolves into something completely obvious. So does this actually mean something like "git uses branches."?
- deleted 5y ago[deleted]
- mhh__ 5y agoIs that maths soup or a real construct? I can't join the dots but I'm also studying physics so category theory is still slightly Greek to me (I can feel the mathematicians' noses rising already...)
- magnio 5y agoIt's a joke. A well-discussed one. https://softwareengineering.stackexchange.com/questions/256450/are-git-branches-in-fact-homeomorphic-endofunctors-mapping-submanifolds-of-a https://softwareengineering.stackexchange.com/questions/2564... https://math.stackexchange.com/questions/675092/does-this-statement-about-hilbert-spaces-make-any-sense https://math.stackexchange.com/questions/675092/does-this-st... https://cs.stackexchange.com/questions/12652/is-there-a-formal-cs-definition-of-vcs-and-file-versions https://cs.stackexchange.com/questions/12652/is-there-a-form...
- inshadows 5y agotl;dr it's a random math soup (from first link)
- z77dj3kl 5y agoIt's random math words put together and doesn't make sense even in isolation.
- JJMcJ 5y agoOr else it's research that won a Fields Medal. There is no middle ground.
- jeltz 5y agoI have never got all these jokes. When my job switched from Subversion to git it took me about one week plus reading a couple of articles to become more productive in git than I ever was in Subversion. Yes, version control is a bit tricky but git is not that hard to understand and was much easier than contemporary Subversion versions.
- avalys 5y agoThings have gotten a little better. But, try to do something off the beaten path in Git, and you may ultimately get the joke. For example: “two weeks ago an intern accidentally committed a file containing IP we’re not allowed to use, we need to erase it from the repository and all developer machines.” Have fun with that one! EDIT: I mean, try to figure this out from the official Git documentation (https://git-scm.com/docs https://git-scm.com/docs). No, Stack Overflow and Github are not the official Git documentation. Believe it or not, the idea that "Git is hard to use" predates Stack Overflow.
- onei 5y agoErase from the repo, a little non-standard, but fine. Being asked to remove it from all developer machines sounds like someone misunderstood how version control works. Was that a real life example you hit?
- karatinversion 5y agoThey might have a model of version control in their head that predates distributed version control systems - I never used one myself, but the code base I work on still has scars here and there from the era when only one developer could have any single file checked out.
- avalys 5y agoGit clones the entire remote repository to each developer's machine. So, if you accidentally committed something you shouldn't have two weeks ago, everyone will now have a copy in their local repo. And you can't always just tell people to delete their local repos and start again, since they might have local branches they're working on, etc.
- deleted 5y ago[deleted]
- SmellTheGlove 5y agoIs this a joke or serious? I don’t understand enough of the words after “branches” to know. I’m serious btw.
- stu2b50 5y agoIt's a parody/derivation from the monad joke, where one explanation for a monad is that they're "just an monoid in the category of endofunctors".
- SmellTheGlove 5y agoHN makes me realize I don't know enough words.
- twic 5y agoA sparse Hilbert space. Beginners make that mistake a lot.
- jjice 5y agoDefinitely helped a bit. I just graduated from university and am working full time as a developer now. I thought I knew how to use git because I knew how to do feature branching and merging. Boy was I wrong. Within a few weeks at my new job, I've realized that I'm missing so much useful git knowledge. When I learned about cherry-pick, my mind was blown. My goal right now is to develop a better mental model of git than what I have right now. If anyone has recommendations for resources, please let me know!
- guhidalg 5y agohttps://learngitbranching.js.org/ https://learngitbranching.js.org/ Go through every lesson, understand it, and find yourself more knowledgeable about git usage than 95% of developers.
- lanstin 5y agoSo true and so worth the extra knowledge to understand your tools. You should also read about the various knobs on your compiler or interpreter from time to time. I used to reread gcc manual every five years, and now I search on the env variables that affect python runtime. Getting ready to that for go build chain now I have 3 or 4 production go things. Similar for my editor and libc and language stblib and kernel APIs, tho they are more diffuse than the gcc manual.
- Forge36 5y agoThis was a good way to pass some time :) I look forward to sharing this with others on my team.
- jlokier 5y agoThis was the best resource for me: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
- leephillips 5y agoThat is a good, clear exposition. Thanks!
- mistrial9 5y agothe industrial-strength rigor of git don't mock or dismiss any of it ! you will do as you must, with every commit for one line of text or puzzle of Rust back to your seat you ignorant grunt
- Sr_developer 5y agoFor me almost every Git teaching resource has gone like this: Step 1.It is explained that Git is a simple program, and that the underlined idea can be understood easily, it is only that other materials have done a bad job about it. Step 2. Tell the reader a blob is just the byte object containing the information you are source-controlling. "See how easy it is?" Step 3. Invent their own nomenclature/diagrams/metaphors for all the other concepts, totally muddling the waters. Step 4. Become one of the resources criticized on Step 1.
- andi999 5y agoOur IT department refuses to give an introduction to git. Smart guys.
- darekkay 5y agoOne day I'd like to break this circle. I've been doing 2-day Git workshops with a colleague for a few years now, and "to internals or not to internals" is our constant disagreement. I don't like talking about blobs, trees and anything below the "commit hash" level because I almost never need it myself. My other personal issue is the complete opposite of the "going way too deep into details" teaching resources: showing clone/commit/push/pull and calling it a day. This leads to resources like ohshitgit.com as things will eventually break when people use commands without understanding what is happening. When doing our workshops, we go through the basics: what is a commit, what is a branch, what is HEAD, what do commands like checkout/reset/rebase do on graph level. This approach demistifies Git without going into internals. It also takes away the fear of "advanced" topics (like "rewriting" history)
- umvi 5y agoI just think of git as a graph and branches/tags as text pointers to nodes in the graph. Doesn't seem that complex to me... Maybe I "got gud" though and can no longer empathize with git beginners
- rubyist5eva 5y agoBecause that's exactly what it is, and it's not. When I explain git to newbies in this way, it's like something clicks in their brain and they just start to "get it" as well.
- lanstin 5y agoEspecially if they took a maths course on graph theory.
- Spivak 5y agoBut then once you get the mental model you spend the other 90% of the time figuring out what magic incantations are needed to transform the graph in the way you want.
- crispyambulance 5y agoThe sad thing is you can't just "figure it out." Most folks do "good-enough" after some coaching and memorizing a limited set of commands needed for their workflow-- until something unexpected happens. It could be a typo, or trying something new, or forgetting/misunderstanding the intent of some counterintuitive command, or maybe cleaning up an existing problem. All those things can easily put someone in a deep rabbit hole of inside git book or, worse, google search.
- nkozyra 5y agoWell it's understandable. Moving nodes in a graph (a tree, really) has a lot of side effects. Couple that with multiple people trying to keep things in sync(ish) and it gets super complex.
- 5y ago
- JJMcJ 5y agoAs always: https://xkcd.com/1597/ https://xkcd.com/1597/
- lanstin 5y agoThis is never not funny.
- andi999 5y agoWill read it, until now, for me,git feels like it tries to get in my way (probably because I think differently). I heard about fossil,(https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki) does anybody have experience with it? Does it suck less?
- hyperman1 5y agoMy experience with git is it's organically grown, and regularly a mess. It works reasonably well and in fact is better than a lot of alternatives, but can become a monster quickly and unexpectedly. My experience with mercurial was better than with git. But none of this matters, as git/github/gitlab is today the industry standard, or even the category killer for version control. You will have to deal with it in one capacity or another. So my advice is to deal with git, learn at least up to medium level. As industry standards go, things could be a lot worse than git.
- lanstin 5y agoThe main thing to know for newbies is as long as you don’t force push to a remote branch, it is safe. You are creating new state only, not destroying. All errors are Recoverable.
- lanstin 5y agoAnd don’t expect the command details to make sense. What you want to do is some simple thing in terms of a graph of states, and just google the command if you aren’t sure it it is origin/branch or origin space branch.
- pjc50 5y agoYou can still easily lose uncommitted local state, which is unrecoverable, and also put the checkout into a state from which a newbie finds it hard to escape.
- usr1106 5y agoEven force pushing is not really a problem. If you don't want to keep every typo and braindead approach in history, force push is a required tool. Naturally things go wrong occasionally, but garbage collection is not run often. You only need to know the SHA-1 and you can fetch "lost" commits again. Old SHA-1s can be found in reflog. We also have all pushes automatically announced all in chat, so you can look up previously pushed SHA-1s in chat history (we use gitlab and zulip and those support it out of the box). Of course you still need a mental model how git history (including history rewriting) works, othwerwise you cannot understand what exactly went wrong. And without knowing what went wrong fixing it gets awkward trial and error, which unfortunately many less experienced git users seem to do.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- belter 5y agoFor the more knowledgeable on Git. What is the current status of the transition from SHA-1 ?
- cerved 5y agohttps://thenewstack.io/git-transitioning-away-from-the-aging-sha-1-hash/ https://thenewstack.io/git-transitioning-away-from-the-aging...
- beermonster 5y agoThis [1] is useful to read. Sha256 supported (experimentally at least) in Git since 2.29[2] [1] https://lwn.net/Articles/811068 https://lwn.net/Articles/811068 [2] https://lore.kernel.org/lkml/xmqqy2k2t77l.fsf@gitster.c.googlers.com/ https://lore.kernel.org/lkml/xmqqy2k2t77l.fsf@gitster.c.goog...
- auggierose 5y agoA friend of mine just posted this today, and I totally agree: https://weisser-zwerg.dev/posts/software-engineering-vcs/ https://weisser-zwerg.dev/posts/software-engineering-vcs/
- IshKebab 5y ago> in my opinion, the majority of projects developed in-house in an organization by a dedicated in-house software engineering team, would be better off following the guiding principles in Why Google Stores Billions of Lines of Code in a Single Repository and rather using something like SVN rather than git. Mmm no thanks! In any case there's no reason you can't use Git itself as a monorepo! You don't have to inflict SVN on people for that. Very weird opinion.
- auggierose 5y agoWell, the one reason would be to avoid having to deal with Git-Apostels who insist on using git "the right way" instead of how you tell them to. If they cannot learn the 3 or 4 ways of calling svn, for sure they cannot use git the way you want them to.
- LAC-Tech 5y agoI'm so sick of git. Yes I know what a directed acyclic graph is. No I don't know what 'checkout' will actually do this time when I run the command. It's been 10 years. It's still confusing people. There's still article after article, book after book written on a tool that should be getting out of a programmers way. Let's try something else.
- dang 5y agoSome past threads: Git for Computer Scientists - https://news.ycombinator.com/item?id=3146466 https://news.ycombinator.com/item?id=3146466 - Oct 2011 (15 comments) Git for Computer Scientists - https://news.ycombinator.com/item?id=1485612 https://news.ycombinator.com/item?id=1485612 - July 2010 (17 comments)
- rapjr9 5y agoI worked on computer science projects for 20 years. At first we had no source management, everyone did whatever they wanted. Then we used CMS, and we occasionally stepped on each others toes but things were better. Then we switched to SVN and nothing much changed except we established a way to hold locks on files while they were being changed. Then we switched to git because the students wanted to learn the cool thing. We started having meetings to teach people git. Meetings about the best way to use git. Meetings to deal with common problems in our use of git. Productivity dropped because everyone now had to deal with git problems. It made my life hell because usually I just wanted to check in my code so it would not get lost, but instead I would continually get forced into reconciling git issues. I would have to resolve issues to get my code checked in because other people had changed something entirely unrelated to my work. I stopped using git and kept my own backups and only checked in code very occasionally so I could get work done. I noticed other people doing the same thing. The main problem I had with using git is it did not match the way we worked. Git assumes there is one person who is the gatekeeper, who decides what gets into the source, and who does some integration and testing. In research there usually is no one in charge of that, instead everyone is responsible for their own code, testing it, and integrating it. The git model was wrong for us, we never used pull requests at all, because there was no one person who understood everything well enough to approve them. Students don't have the experience or time to be the integrator, the profs don't even write code, and I had multiple other things that I had to do. So using git made a mess of what had been a simple process previously. Git was designed by Linus to make his life easier in managing changes to a kernel. It does not work well in other scenarios and should not be used in many circumstances. Yes, you can make it work, but at a cost.
- ChrisArchitect 5y agogeezus this is old, has there not been more recent versions/attempts at this kind of post?
- ChrisArchitect 5y agoalso, is submitted almost annually with hardly any interest at all. Because either everyone has seen it already around for a decade, and/or it's actually not much of an article.