Earlier 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…
Git for Computer Scientists (2010)
31–40 of 110 posts
Re: Git for Computer Scientists (2010)
#32Earlier 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…
Re: Git for Computer Scientists (2010)
#33Earlier 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…
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?
Re: Git for Computer Scientists (2010)
#34Re: Git for Computer Scientists (2010)
#35I 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
Re: Git for Computer Scientists (2010)
#36Will 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?
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.
Re: Git for Computer Scientists (2010)
#37Will 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?
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.
Re: Git for Computer Scientists (2010)
#38I 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
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.
Re: Git for Computer Scientists (2010)
#39Will 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?
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 ca…
Re: Git for Computer Scientists (2010)
#40Earlier quoted context omitted.
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 ca…
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.