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

71–80 of 110 posts

Re: Git for Computer Scientists (2010)

#71

Post by pjc50 »

lanstin wrote: post #39
hyperman1 wrote: post #36

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.

You can still easily lose uncommitted local state, which is unrecoverable, and also put the checkout into a state from which a newbie finds it hard to escape.

Re: Git for Computer Scientists (2010)

#72

Post by Izkata »

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

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.

Re: Git for Computer Scientists (2010)

#73

Post by LAC-Tech »

I'm so sick of git.

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.

Re: Git for Computer Scientists (2010)

#75

Post by LAC-Tech »

u801e wrote: post #61
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…

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

Re: Git for Computer Scientists (2010)

#76

Post by jollybean »

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

Re: Git for Computer Scientists (2010)

#77

Post by nerdponx »

pjc50 wrote: post #69
CountSessine wrote: post #45

Earlier quoted context omitted.

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.

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.

Re: Git for Computer Scientists (2010)

#78

Post by nerdponx »

sleepychu wrote: post #48
CountSessine wrote: post #45

Earlier quoted context omitted.

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

`git checkout` great for switching to a different commit and for throwing away local unstaged changes!

Using `git checkout` with a filename really really really should have a yes/no prompt by default, or at least an `-i` option like `rm`.

Re: Git for Computer Scientists (2010)

#79

Post by jollybean »

jeltz wrote: post #8
throw0101a wrote: post #2

I ran across this little gem recently: > 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

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.

I often wonder about this as well, but I think there must be a difference of opinion of what 'hard' is.

I think that people think they are confident about Git in 'a few weeks' are basically have a lack of self-awareness. They 'don't know what they don't know'.

I've seen countless times, developers huddled around someone else's computer, trying to figure out what went wrong.

I saw a git animation/visualisation tool once that animated operations, and I saw things happening I had never seen before, basically a lot of 'loose end' things that I didn't even know existed.

I also wonder if that has something to do with the fact that such things are maybe not suited to 'command line' and are inherently structured.

Re: Git for Computer Scientists (2010)

#80

Post by Forge36 »

guhidalg wrote: post #11
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…

https://learngitbranching.js.org/ Go through every lesson, understand it, and find yourself more knowledgeable about git usage than 95% of developers.

This was a good way to pass some time :)

I look forward to sharing this with others on my team.

Post reply on HN