Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git for Computer Scientists (2010)

eagain.net

Post reply on HN
Print view View original

61–70 of 110 posts

Re: Git for Computer Scientists (2010)

#61

Post by u801e »

avalys wrote: post #25
jeltz wrote: 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…

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

Re: Git for Computer Scientists (2010)

#62

Post by darekkay »

Sr_developer wrote: post #14

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…

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)

Re: Git for Computer Scientists (2010)

#63

Post by booleandilemma »

andi999 wrote: post #55
booleandilemma wrote: post #37

Earlier quoted context omitted.

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…

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?

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.

Re: Git for Computer Scientists (2010)

#65

Post by wrycoder »

edp wrote: post #50
avalys wrote: post #25

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

I don't think this is even possible with SVN or CVS, is it ?

It’s very easy in CVS, which is why some people prefer CVS to any distributed solution.

Re: Git for Computer Scientists (2010)

#66

Post by maxnoe »

darekkay wrote: post #62
Sr_developer wrote: post #14

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…

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: showin…

I also take this middle ground, seems to work well for most students

Re: Git for Computer Scientists (2010)

#67

Post by taberiand »

CountSessine wrote: post #45
umvi wrote: 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

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’…

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'

Re: Git for Computer Scientists (2010)

#68

Post by pjc50 »

onei wrote: post #30
avalys wrote: post #25

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

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.

Re: Git for Computer Scientists (2010)

#69

Post by pjc50 »

CountSessine wrote: post #45
umvi wrote: 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

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’…

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.

Re: Git for Computer Scientists (2010)

#70

Post by leephillips »

jlokier wrote: post #13
jjice wrote: post #9

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 tha…

This was the best resource for me: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

That is a good, clear exposition. Thanks!
Post reply on HN