https://blog.plover.com/2022/06/29/#tips The Universe of Discourse Mark Dominus (Tao Wed, 29 Jun 2022 Min Xiu ) mjd@pobox.com Things I wish everyone knew about Git (Part I) [TOP] This is a writeup of a talk I gave in December for my previous employer. It's long so I'm publishing About me it in several parts: RSS Atom * Part I (you are here): + How to approach Git; general strategy 12 recent entries + Read Git From the Bottom Up * Part II: (coming later) Things I wish + It is really hard to lose stuff everyone knew + But what if you do lose something? about Git (Part + Finding old stuff with git-reflog I) + What if you can't find it? Disabling the + What if you don't like something you did? awful Macbook + Git leaves a trail screen lock key + A few things can be lost forever! "Llaves" and + git-rev-parse other vanishing * More coming later still: consonants + Branches are fictitious Quick Spanish + Committing partial changes etymology + Push and fetch; tracking branches question + Aliases and custom commands What's long and hard? Cathedrals of various sorts How to approach Git; general strategy The disembodied heads of Oz Git has an elegant and powerful underlying model Mental illness, based on a few simple concepts: attention deficit disorder, and 1. Commits are immutable snapshots of the suffering repository What was wrong 2. Branches are named sequences of commits with SML? 3. Every object has a unique ID, derived from its Unordered pairs content and the axiom of binary choice black and white white inkdiagram of the elegant Pushing back geometry of the floor plan of a cathedral against contract demands is scary Built atop this elegant system is a flaming trash but please try pile. anyway Let's go find literal dumpster fire out! The command set wasn't always well thought out, and Archive: then over the years it grew by accretion, with new stuff piled on top of old stuff that couldn't be 2022: JFMAMJ changed because Backward Compatibility. The 2021: JFMAMJ commands are non-orthogonal and when two commands JASOND perform the same task they often have inconsistent 2020: JFMAMJ options or are described with different JASOND terminology. Even when the individual commands 2019: JFMAMJ don't conflict with one another, they are often JASOND badly-designed and confusing. The documentation is 2018: JFMAMJ often very poorly written. JASOND 2017: JFMAMJ What this means JASOND 2016: JFMAMJ With a lot of software, you can opt to use it at a JASOND surface level without understanding it at a deeper 2015: JFMAMJ level: JASOND 2014: JFMAMJ "I don't need to know how it works. JASOND I just want to know which commands to run." 2013: JFMAMJ JASOND This is often an effective strategy, but 2012: JFMAMJ JASOND with Git, this does not work. 2011: JFMAMJ JASOND You can't "just know which commands to run" because 2010: JFMAMJ the commands do not make sense! JASOND 2009: JFMAMJ To work effectively with Git, you must have a model JASOND of what the repository is like, so that you can 2008: JFMAMJ formulate questions like "is the repo on this state JASOND or that state?" and "the repo is in this state, how 2007: JFMAMJ do I get it into that state?". At that point you JASOND look around for a command that answers your 2006: JFMAMJ question, and there are probably several ways to do JASOND what you want. 2005: OND But if you try to understand the commands without the model, you will suffer, because the commands do ----------------- not make sense. Subtopics: Just a few examples: Mathematics 217 Programming 80 * git-reset does up to three different things, Language 77 depending on flags Miscellaneous 57 Book 47 * git-checkout is worse Tech 41 Oops 29 * The opposite of git-push is not git-pull, it's Unix 26 git-fetch Cosmic Call 25 Haskell 24 * etc. Etymology 24 Physics 21 If you try to understand the commands without a Law 17 clear idea of the model, you'll be perpetually Perl 16 confused about what is happening and why, and you Math SE 15 won't know what questions to ask to find out what is going on. [mjd-univer] Higher-Order Perl Blosxom READ THIS Comments disabled When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. The magic key that rescued me was John Wiegley's Git From the Bottom Up Git From the Bottom Up explains the model. I read it. After that I wept no more. I understood what was going on. I knew how to try things out and how to interpret what I saw. Even when I got a surprise, I had a model to fit it into. You should read it too. That's the best advice I have. Read Wiegley's explanation. Set aside time to go over it carefully and try out his examples. It fixed me. If I were going to tell every programmer just one thing about Git, that would be it. The rest of this series is all downhill from here. But if I were going to tell everyone just one more thing, it would be: It is very hard to permanently lose work. If something seems to have gone wrong, don't panic. Remain calm and ask an expert. Many more details about that will be in next week's followup article. [Other articles in category /prog/git] permanent link