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

81–90 of 110 posts

Re: Git for Computer Scientists (2010)

#81

Post by crispyambulance »

Igelau wrote: post #28
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

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.

The hard part of git has never been the understanding its graph model.

The hard part HAS ALWAYS BEEN is memorizing all those badly named and counterintuitive commands.

Re: Git for Computer Scientists (2010)

#82

Post by crispyambulance »

Spivak wrote: post #52
rubyist5eva wrote: post #22

Earlier quoted context omitted.

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.

But then once you get the mental model you spend the other 90% of the time figuring out what magic incantations are needed to transform the graph in the way you want.

The sad thing is you can't just "figure it out." Most folks do "good-enough" after some coaching and memorizing a limited set of commands needed for their workflow-- until something unexpected happens.

It could be a typo, or trying something new, or forgetting/misunderstanding the intent of some counterintuitive command, or maybe cleaning up an existing problem. All those things can easily put someone in a deep rabbit hole of inside git book or, worse, google search.

Re: Git for Computer Scientists (2010)

#83

Post by yawaramin »

pjc50 wrote: post #68
onei wrote: post #30

Earlier quoted context omitted.

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.

It's rather simple: remove it from the origin repo using BFG Cleaner or whatever, then ask devs to delete and re-clone the repo. Not everything needs a complex technical solution.

Re: Git for Computer Scientists (2010)

#84

Post by nkozyra »

crispyambulance wrote: post #82
Spivak wrote: post #52

Earlier quoted context omitted.

But then once you get the mental model you spend the other 90% of the time figuring out what magic incantations are needed to transform the graph in the way you want.

The sad thing is you can't just "figure it out." Most folks do "good-enough" after some coaching and memorizing a limited set of commands needed for their workflow-- until something unexpected happens. It could be a typo, or trying something new, or forgetting/misunderstanding the intent of some counterintuitive command, or maybe cleaning up an existing problem. All those things can easily put someone in a deep rabbi…

Well it's understandable. Moving nodes in a graph (a tree, really) has a lot of side effects. Couple that with multiple people trying to keep things in sync(ish) and it gets super complex.

Re: Git for Computer Scientists (2010)

#87

Post by yencabulator »

nerdponx wrote: post #77
pjc50 wrote: post #69

Earlier quoted context omitted.

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.

Pull defaulting to rebase could be a dangerous and chaotic default. If you want to argue that pulling should be fast-forward-only, then I'd say maybe you have a case.

I have aliases ff for fast-forward-only merges and puff for fast-forward-only pulls. I never type `git pull` anymore, and it's much harder to shoot your foot off with the aliases.

Re: Git for Computer Scientists (2010)

#88

Post by sigjuice »

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…

Curious why the IP address has to be obliterated from history instead of just correcting it in a new commit? An IP does not seem sensitive like a secret or private key.

EDIT: Sorry, my bad. I misread.

Re: Git for Computer Scientists (2010)

#89

Post by u801e »

LAC-Tech wrote: post #75
u801e wrote: post #61

Earlier quoted context omitted.

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

> git log -p origin/master..HEAD See THIS is the problem. Ugly, inconsistent, clumsy use of the english language, and confusing. This will go on my git sheet, with a comment as to what it actually does because I don't have the time to actually unpack that from first principles. I've got better things to do than become an expert on needlessly complicated software.

> See THIS is the problem. Ugly, inconsistent, clumsy use of the english language, and confusing.

It's a command line interface, not plain English. What's ugly and inconsistent about the git log command as was quoted in your reply?

> I've got better things to do than become an expert on needlessly complicated software.

As a software developer, I have to read through a lot of documentation to be able to use programming languages, SQL, data stores, unix utils, etc. I don't see why it would be any different for a VCS.

I think the actual issue is that people aren't willing to read through the documentation to understand what a command does and what options are available.

As for the command itself, the -p switch shows the diff associated with each commit shown with the git-log command. origin/master represents the upstream tracking branch of the master branch (most likely the base branch that the person is working on). .. represents a range operator and HEAD repesents the commit that's the latest commit on the branch on the local machine.

Re: Git for Computer Scientists (2010)

#90

Post by LegionMammal978 »

sigjuice wrote: post #88
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…

Curious why the IP address has to be obliterated from history instead of just correcting it in a new commit? An IP does not seem sensitive like a secret or private key. EDIT: Sorry, my bad. I misread.

Presumably they did not mean an Internet Protocol address, but instead data containing disallowed intellectual property.
Post reply on HN