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

Beej's Guide to Git

beej.us

Post reply on HN
Print view View original

111–120 of 318 posts

Re: Beej's Guide to Git

#111

Post by riffraff »

stephen_g wrote: post #16
vvpan wrote: post #14

Earlier quoted context omitted.

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.

Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning.

Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs.

Compare git diff with hg diff for example.

Re: Beej's Guide to Git

#112

Post by beej71 »

wunderlust wrote: post #106

Why are there so many guides to git?

Because it's challenging to use, and writing effectively about challenging-to-use things is a really fun challenge.

At least, that's why I'm in it. That, and to do my best to help students succeed.

Re: Beej's Guide to Git

#113

Post by pknerd »

20k wrote: post #64
scrapcode wrote: post #26

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself

It is still better than (As)SVN

Re: Beej's Guide to Git

#115

Post by rswail »

chasil wrote: post #48
ajross wrote: post #43

Earlier quoted context omitted.

My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…

The deal killer for me, the inescapable aspect of my users, is that they insist upon checking passwords into revision control. Because the C and PL/SQL people are on CVS, I can fix this with vi on the ,v archive. First on TFS repositories, and now with git grep I can easily find exposed passwords for many things. But it's just SQL Server! We will never be able to use git responsibly, so I will peruse this guide with…

Sounds like you need a pre-commit hook to check.

Re: Beej's Guide to Git

#116

Post by wruza »

gitgood wrote: post #86
ajross wrote: post #83

Earlier quoted context omitted.

Pretty much, yeah. Just do the work. It's not nearly as hard as whatever it is you're committing into it, I promise. Continuing to mock it via florid metaphor doesn't help anyone at this point.

I'm always kind of aghast at the number of people who not only don't know git, but who cannot or will not learn it over years, or even decades. Listen, I'm not that smart, and I managed to figure out how to solve even gnarly git issues one summer during an internship... 11 years ago? Ish? Now, I know git well, and not just "the three commands". I would be, honestly, so ashamed if it were a decade on and I still hadn'…

If people can't learn git, I wouldn't trust them with the even harder parts of software development.

This idea breaks under pressure. People have limited concentration and the more you demand for daily routine, the less there’s left for the actual job. This argument only makes sense in a relaxed setting with lots of time and coffee breaks. But all these problems tend to happen at friday evening when you’re expected to get your kids in an hour or something and this damn repo got broken again.

Yes, things should be easier. Cause you get what you get. If you want people who have no issues with git, feel free to enjoy the greatly reduced hiring pool and stop whining about someone not being able to juggle fifty things at once in their mind - focus on your hiring process and where to get the budget for inflated compensation instead.

Is it any wonder software today is so bad?

I remember delphi and vb time, when people - who were unable to understand or use CVS and SVN - made full-blown apps for real sectors, and it worked. Because it was easy. Nowadays all we have is important dudes with pseudo-deep knowledge of git, css, framework-of-the-month and a collection of playbooks, who cannot make a db-enabled hello username message box in less than a day. I don’t think you’re moving in the right direction at all with this. This paradigm is going further and further from good software, actually.

Re: Beej's Guide to Git

#118

Post by beej71 »

at_a_remove wrote: post #62
beej71 wrote: post #42

Earlier quoted context omitted.

If you do check it out and there are parts that are confusing, I'd love to hear about it.

This is partially a question and the rest is shameful confession: I had haltingly used cvs as a solo programmer, and when I was suddenly no longer a solo programmer and had to use git, everything went haywire. I am an Old and we never were taught anything about coding with other people who were also working on the same project. I have had many successful projects but never with another person. With that as a backgrou…

1) I say it happens automagically. :) I'm not really familiar with merging strategies, but I would imagine that it happens in a way similar to a diff. But it only works if the changes are "distant" from one another. If they are happening too close in the file, Git punts and tells you there's a conflict you have to manually resolve.

2) I try to stay out of holy wars. Use the right tool for the job, I say, and sometimes that could even be Emacs. ;) I do talk about a few of the more common options for branching in teams (mostly focused on the small teams we tend to have here in university). And I talk about their pros and cons. But I stop short of declaring one the winner since the best option depends on the circumstances. IMHO.

3) I've seen repos with big functions and small functions, so I don't think it's a Git thing. Students tend to write functions that do too much and are too large, but it's certainly possible to break things down into pieces that are prohibitively tiny. Overall this seems more of a software engineering design choice than anything Git-related.

Re: Beej's Guide to Git

#119

Post by sampullman »

ujkiolp wrote: post #100
sampullman wrote: post #91

Earlier quoted context omitted.

I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too co…

>It did take maybe a year or so we have normalized this for git - a tool to store versions of text. That’s the problem

A folder with a list of files is a tool to store versions of text. Git is somewhat more useful.

Re: Beej's Guide to Git

#120

Post by crabbone »

20k wrote: post #64
scrapcode wrote: post #26

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use Learning git like this is honestly just hampering yourself

Not at all. Not in the least.

The worst part about Git is the bad defaults. Seconded only by mismanaged storage. Or maybe being designed for the use-case most of its users will never have. Or maybe horrible authentication mechanism. Or maybe the lack of bug-tracker or any sensible feedback from its developers.

None of this can be helped by the GUI. In fact, beside Magit, any sort of front-end to Git I've seen is hands down awful and teaches to do the wrong thing, and is usually very difficult to use efficiently, and mystifies how things actually work. But, even with Magit, I'd still advise to get familiar with CLI and configuration files prior to using it: it would make it easier to understand what operations is it trying to improve.

Post reply on HN