For the more knowledgeable on Git. What is the current status of the transition from SHA-1 ?
Git for Computer Scientists (2010)
41–50 of 110 posts
Re: Git for Computer Scientists (2010)
#42Definitely 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 tha…
https://learngitbranching.js.org/ Go through every lesson, understand it, and find yourself more knowledgeable about git usage than 95% of developers.
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.
Re: Git for Computer Scientists (2010)
#43As always: https://xkcd.com/1597/
This is never not funny.
Re: Git for Computer Scientists (2010)
#44I 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
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]
Re: Git for Computer Scientists (2010)
#45I 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
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).
Re: Git for Computer Scientists (2010)
#46Earlier quoted context omitted.
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.co…
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?
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.
Re: Git for Computer Scientists (2010)
#47Will 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?
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…
So if I understand correctly there’s no equivalent to git squash merging branches?
Re: Git for Computer Scientists (2010)
#48I 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
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’…
`git checkout` great for switching to a different commit and for throwing away local unstaged changes!
Re: Git for Computer Scientists (2010)
#49Earlier quoted context omitted.
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.co…
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?
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.
Re: Git for Computer Scientists (2010)
#50Earlier quoted context omitted.
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.
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.co…
I don't think this is even possible with SVN or CVS, is it ?