Live data from Hacker News

Git for Computer Scientists (2010)

eagain.net

31–40 of 110 posts

Re: Git for Computer Scientists (2010)

#31
post #25
post #8

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…

It's all documented https://docs.github.com/en/github/authenticating-to-github/k...

Re: Git for Computer Scientists (2010)

#32
post #25
post #8

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…

[deleted]

Re: Git for Computer Scientists (2010)

#33
post #25
post #8

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…

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?

Re: Git for Computer Scientists (2010)

#36
post #27

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?

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.

Re: Git for Computer Scientists (2010)

#37
post #27

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.

Re: Git for Computer Scientists (2010)

#38
post #20

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

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.

Especially if they took a maths course on graph theory.

Re: Git for Computer Scientists (2010)

#39
post #27

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?

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.

Re: Git for Computer Scientists (2010)

#40
post #39

Earlier 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.

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.
Post reply on HN