[HN Gopher] Git for Computer Scientists (2010)
___________________________________________________________________
Git for Computer Scientists (2010)
Author : thanato0s
Score : 203 points
Date : 2021-06-13 10:06 UTC (12 hours ago)
(HTM) web link (eagain.net)
(TXT) w3m dump (eagain.net)
| umvi wrote:
| I 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
| nerdponx wrote:
| That's pretty much the gist of the article, no?
| cerved wrote:
| That's what makes it good :)
|
| I had no idea why it took my brain so long to wrap my head
| around it. Maybe it was blissful ignorance, never sitting
| down and making a mental model of it. Always looking for a
| tldr version of doing things. I don't know exactly at which
| point things clicked but it went from bewildering to just
| makes sense
| CountSessine wrote:
| The git plumbing and plumbing commands are straightforward and
| easy enough to understand once you read about them a bit (I
| recommend the free Pro Git book online).
|
| The original git porcelain commands - _git branch_ , _git
| reset_ , _git pull_ - are execrable. They're filled with
| implementation details (index /cache vs staging), weird and
| suggestive syntax that seems like it should be extensible and
| widely applicable but isn't (localbranch:remotebranch), and
| nuclear-powered self-destruct functionality hidden amongst
| playthings (git reset vs git reset --hard).
| sleepychu wrote:
| `git checkout` great for switching to a different commit
| _and_ for throwing away local unstaged changes!
| nerdponx wrote:
| Using `git checkout` with a filename really really really
| should have a yes/no prompt by default, or at least an `-i`
| option like `rm`.
| taberiand wrote:
| It sounds like git in general isn't necessarily the problem
| (at least after getting the basic model down), it's
| specifically the interface and associated foot-guns it sticks
| in there for beginners (and tired experts) to trip over.
|
| Most people most of the time will get by if they grab a
| decent git GUI, figure out the minimal set of operations they
| need, and just Google the rest when necessary.
|
| My stupidest git mistake was when I was cleaning out a
| directory of bin and obj folders and included gits obj folder
| as well. And of course after crying in the corner for a bit I
| take a little time to look into git commands and I could have
| just run 'git clean'
| pjc50 wrote:
| Two additional bad defaults: crlf handling on Windows, and
| pull not defaulting to rebase.
|
| The message "up to date with origin/master" is also
| misleading, because it doesn't check the remote itself.
| nerdponx wrote:
| Pull defaulting to rebase could be a dangerous and chaotic
| default. If you want to argue that pulling should be fast-
| forward-only, then I'd say maybe you have a case.
| rubyist5eva wrote:
| Because 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.
| Spivak wrote:
| But 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 wrote:
| The 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 wrote:
| Well 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.
| lanstin wrote:
| Especially if they took a maths course on graph theory.
| cerved wrote:
| I think all that is needed is an aha moment
| RobRivera wrote:
| i honestly feel people are allergic to rtfm
| Igelau wrote:
| It _could_ be hard if you never took Discrete or another course
| that introduces graph theory. Or if you cheated your way
| through or barely scraped by. I can see how a CS freshman or
| someone from another field might struggle, but even then it 's
| more comprehensible than any of the alternatives.
| crispyambulance wrote:
| The hard part of git has never been the understanding its
| graph model.
|
| The hard part HAS ALWAYS BEEN is memorizing all those badly
| named and counterintuitive commands.
| Izkata wrote:
| Yeah, something along these lines is how I've explained it to
| co-workers as well. Tossing in "git log --all --oneline
| --decorate --graph" so they can actually _see_ the graph also
| helps a lot.
| jollybean wrote:
| The 'complex' part usually relates to how to manage the graph
| in terms of what you want to do, and all the odd states that
| might exist otherwise, especially when syncing with 'other
| graphs'.
| JJMcJ wrote:
| As always: https://xkcd.com/1597/
| lanstin wrote:
| This is never not funny.
| jjice wrote:
| Definitely 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!
| macintux wrote:
| Jessica Kerr (jessitron) gives a good git internals talk that
| you can find on YouTube if that's a helpful learning style.
| guhidalg wrote:
| https://learngitbranching.js.org/
|
| Go through every lesson, understand it, and find yourself more
| knowledgeable about git usage than 95% of developers.
| lanstin wrote:
| So 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 wrote:
| This was a good way to pass some time :)
|
| I look forward to sharing this with others on my team.
| jlokier wrote:
| This was the best resource for me:
|
| http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
| leephillips wrote:
| That is a good, clear exposition. Thanks!
| Sr_developer wrote:
| For 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 wrote:
| Our IT department refuses to give an introduction to git. Smart
| guys.
| darekkay wrote:
| One 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)
| maxnoe wrote:
| I also take this middle ground, seems to work well for most
| students
| auggierose wrote:
| A friend of mine just posted this today, and I totally agree:
|
| https://weisser-zwerg.dev/posts/software-engineering-vcs/
| throw0101a wrote:
| I 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
| jeltz wrote:
| I 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 wrote:
| Things 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). 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.
| edp wrote:
| I don't think this is even possible with SVN or CVS, is it
| ?
| wrycoder wrote:
| It's very easy in CVS, which is why some people prefer
| CVS to any distributed solution.
| MarkSweep wrote:
| At least with SVN, the is one option that is pretty
| similar to git's filter-branch: svndumpfilter. You dump
| the entire history of the SVN repo to a file, edit it,
| and then load it into a new SVN repo. I used this
| technique to pre-process a repo to remove large files
| before migrating to Git. The file format is simple enough
| that you can easily write a program to edit the stream.
| onei wrote:
| Erase 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 wrote:
| They 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.
| pjc50 wrote:
| Not a misunderstanding, a requirement. If the developers
| cannot have that data (legal reasons? Secrets?) it must
| be deleted.
|
| Probably has to be done outside git, though. Maybe one of
| the corporate virus scanners will let you definite a
| local signature.
| yawaramin wrote:
| It's rather simple: remove it from the origin repo using
| BFG Cleaner or whatever, then ask devs to delete and re-
| clone the repo. Not everything needs a complex technical
| solution.
| avalys wrote:
| Git 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.
| yawaramin wrote:
| It's all documented
| https://docs.github.com/en/github/authenticating-to-
| github/k...
| [deleted]
| jeltz wrote:
| I have had to do it once during the 12 years I have used
| git, so I seriously doubt that this is why people think git
| is hard. And I think that googling it would be fine in that
| case. That said: since I have done it once I could easily
| figure out how to do it again and it wasn't hard, just a
| bit cumbersome due to git's distributed nature.
| aardshark wrote:
| Is Googling not allowed? This situation is pretty common,
| so there are plenty of SO answers and articles on how to
| accomplish rewriting history to erase it from the repo.
|
| Removing from developer machines is a separate issue and
| requires you to be able to coordinate your Devs.
|
| If you meant that it's not simple to work out from scratch
| what you should do without lots of reading and trial and
| error...that kinda goes for a lot of tools, no?
| Spivak wrote:
| Yes but git seems to be one of those tools where
| laypeople seems to genuinely not be able to derive how to
| do complex tasks from first principles. Lord knows I
| can't. If your Googling doesn't turn up someone's who's
| had your exact problem you will have to burn a long time
| figuring out how to do what you want.
| u801e wrote:
| > 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."
|
| Technically, the issue was actually pushing that commit to
| the remote repository.
|
| I think the best advise one can give people when using it
| is to to run: git log -p
| origin/master..HEAD
|
| and look at the commit messages and associated diffs to see
| if there's anything there that shouldn't be there before
| the actually run git push.
| LAC-Tech wrote:
| > git log -p origin/master..HEAD
|
| See THIS is the problem. Ugly, inconsistent, clumsy use
| of the english language, and confusing.
|
| This will go on my git sheet, with a comment as to what
| it actually does because I don't have the time to
| actually unpack that from first principles. I've got
| better things to do than become an expert on needlessly
| complicated software.
| jollybean wrote:
| I often wonder about this as well, but I think there must be
| a difference of opinion of what 'hard' is.
|
| I think that people think they are confident about Git in 'a
| few weeks' are basically have a lack of self-awareness. They
| 'don't know what they don't know'.
|
| I've seen countless times, developers huddled around someone
| else's computer, trying to figure out what went wrong.
|
| I saw a git animation/visualisation tool once that animated
| operations, and I saw things happening I had never seen
| before, basically a lot of 'loose end' things that I didn't
| even know existed.
|
| I also wonder if that has something to do with the fact that
| such things are maybe not suited to 'command line' and are
| inherently structured.
| SkyMarshal wrote:
| _> I have never got all these jokes._
|
| If you mean that literally, this joke is referencing another
| joke meme in the functional programming community, explained
| here: https://blog.merovius.de/2018/01/08/monads-are-just-
| monoids....
|
| If you mean, you don't get why people joke about Git being
| hard, it probably isn't for most professional programmers
| already accustomed to some kind of source control, just
| perhaps to anyone new to it.
| twic wrote:
| A _sparse_ Hilbert space. Beginners make that mistake a lot.
| [deleted]
| beermonster wrote:
| See also this
|
| https://git-man-page-generator.lokaltog.net/
| JJMcJ wrote:
| Reads like the man page for "git rebase".
| question000 wrote:
| Richard 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]
| mhh__ wrote:
| Is 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 wrote:
| It's a joke. A well-discussed one.
|
| https://softwareengineering.stackexchange.com/questions/2564.
| ..
|
| https://math.stackexchange.com/questions/675092/does-this-
| st...
|
| https://cs.stackexchange.com/questions/12652/is-there-a-
| form...
| inshadows wrote:
| tl;dr it's a random math soup (from first link)
| z77dj3kl wrote:
| It's random math words put together and doesn't make sense
| even in isolation.
| JJMcJ wrote:
| Or else it's research that won a Fields Medal. There is no
| middle ground.
| SmellTheGlove wrote:
| Is this a joke or serious? I don't understand enough of the
| words after "branches" to know. I'm serious btw.
| stu2b50 wrote:
| It'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".
| mistrial9 wrote:
| _the 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_
| andi999 wrote:
| Will 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) does anybody have experience with it? Does it suck
| less?
| hyperman1 wrote:
| My 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 wrote:
| The 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.
| pjc50 wrote:
| You 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.
| lanstin wrote:
| And 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.
| booleandilemma wrote:
| I think there are 2 core principles governing fossil:
|
| 1) It wants to be the only tool you need to bring with you if
| you and your fellow developers are going to be stuck on a
| desert island. It's not only version control, but also an issue
| tracker, and more recently a chat app.
|
| 2) It preserves everything you commit to it. Whereas git lets
| you polish your commit history before pushing, fossil keeps
| everything. You can't alter your local history. All your messy
| scratch work can't be cleaned up. It's visible forever.
|
| That second point is what turns me off to it, so I've stuck
| with git for personal projects. When I push up my local code, I
| like to have a very clean history.
| andi999 wrote:
| Thanks. They really seem to have a bias against deleting (and
| not so good rationalizations):https://fossil-
| scm.org/home/doc/trunk/www/shunning.wiki
|
| Apart from that, did you try it, and was it smooth?
| booleandilemma wrote:
| I tried it just for an afternoon, but I did find it easy to
| work with.
|
| I find git easy to work with too though, as long as
| everyone sticks to a well-defined workflow and doesn't do
| anything weird.
| stingraycharles wrote:
| So if I understand correctly there's no equivalent to git
| squash merging branches?
| [deleted]
| LAC-Tech wrote:
| I'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 wrote:
| Some past threads:
|
| _Git for Computer Scientists_ -
| https://news.ycombinator.com/item?id=3146466 - Oct 2011 (15
| comments)
|
| _Git for Computer Scientists_ -
| https://news.ycombinator.com/item?id=1485612 - July 2010 (17
| comments)
| belter wrote:
| For the more knowledgeable on Git. What is the current status of
| the transition from SHA-1 ?
| cerved wrote:
| https://thenewstack.io/git-transitioning-away-from-the-aging...
| beermonster wrote:
| This [1] is useful to read. Sha256 supported (experimentally at
| least) in Git since 2.29[2]
|
| [1] https://lwn.net/Articles/811068
|
| [2]
| https://lore.kernel.org/lkml/xmqqy2k2t77l.fsf@gitster.c.goog...
| [deleted]
___________________________________________________________________
(page generated 2021-06-13 23:00 UTC)