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).
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.
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.
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.
I think that's a fine perspective for a computer scientist or graph theorist, myself. Fortunately, since the article title is "Git for Computer Scientists," that's essentially the approach the article takes. :-)
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'.
> 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.
I 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.
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?
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.
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.
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!
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.
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."?
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.
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...)
also, 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.
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.
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)
umvi|4 years ago
Maybe I "got gud" though and can no longer empathize with git beginners
CountSessine|4 years ago
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).
Izkata|4 years ago
rubyist5eva|4 years ago
Igelau|4 years ago
IshKebab|4 years ago
Give any Git newbie a decent GUI and a translation for Git terminology into sane terminology and they will have no problems.
actually_a_dog|4 years ago
jollybean|4 years ago
nerdponx|4 years ago
cerved|4 years ago
RobRivera|4 years ago
auggierose|4 years ago
https://weisser-zwerg.dev/posts/software-engineering-vcs/
IshKebab|4 years ago
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.
rapjr9|4 years ago
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.
andi999|4 years ago
booleandilemma|4 years ago
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.
hyperman1|4 years ago
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.
jjice|4 years ago
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|4 years ago
Go through every lesson, understand it, and find yourself more knowledgeable about git usage than 95% of developers.
jlokier|4 years ago
http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
macintux|4 years ago
dang|4 years ago
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)
unknown|4 years ago
[deleted]
JJMcJ|4 years ago
lanstin|4 years ago
LAC-Tech|4 years ago
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.
belter|4 years ago
beermonster|4 years ago
[1] https://lwn.net/Articles/811068
[2] https://lore.kernel.org/lkml/xmqqy2k2t77l.fsf@gitster.c.goog...
cerved|4 years ago
throw0101a|4 years ago
> 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
question000|4 years ago
jeltz|4 years ago
beermonster|4 years ago
https://git-man-page-generator.lokaltog.net/
twic|4 years ago
SmellTheGlove|4 years ago
mhh__|4 years ago
unknown|4 years ago
[deleted]
ChrisArchitect|4 years ago
ChrisArchitect|4 years ago
unknown|4 years ago
[deleted]
Sr_developer|4 years ago
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.
darekkay|4 years ago
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)
andi999|4 years ago
mistrial9|4 years ago
[deleted]