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

171–180 of 318 posts

Re: Beej's Guide to Git

#171

Post by account42 »

riffraff wrote: post #111
stephen_g wrote: post #16

Earlier quoted context omitted.

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.

I've never been confused by git checkout. git checkout switches to a branch. git checkout switches to a commit in a detached head state. git checkout switches just the content of a file. You can also combine these ofc but it all works pretty much as expected. The -b switch for creating new branches is someting you need to look up once and then just remember - and it does make sense - you are switching to a new branch.

Re: Beej's Guide to Git

#172

Post by kali_00 »

beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Not wrong, but something I found confusing, in section 2.7.5 (page 11 of PDF):

"Let's say you modified foo.txt but didn't add it. You could: "

Followed by:

"And that would add it and make the commit. You can only do this with files you added before."

Wait, what? So, I modified foo.txt but didn't add it, and then the command to add and commit at the same time can only be done with files I did add before?

Guide was working great to heal years of git trauma up until that point though!

Re: Beej's Guide to Git

#173

Post by delta_p_delta_x »

ajross wrote: post #166
wruza wrote: post #110

Earlier quoted context omitted.

This doesn’t work. Look: Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes. Do I understand git? Seems like yes. Let’s run a quiz then! Q? A. How to make a branch? Git branch -a? Git checkout -b --ne…

Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. If you insist on memorizing commands for all these tasks (of which there are many ), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it…

Not the parent commenter. Git the version control system is superb, fast, robust, well-thought out. Git the CLI tool is by far one of the worst CLIs I have ever had the misfortune of using. I think the one-dimensional, string-y command-line massively complicates mental and reasoning models for a tool with a fundamental data structure—a tree—that is multi-dimensional.

A powerful Git GUI makes even moderately-complicated actions like cherry-picking, interactive rebasing, and even ref-logging absolutely trivial. In fact it was precisely said GUI tool that allowed me to develop an intuition for how Git worked internally; the CLI does no such thing.

Re: Beej's Guide to Git

#175

Post by usrme »

aidos wrote: post #148
beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.

This is a fantastic mention! I've been commenting out my commit message lines and then saving as a way to trigger this. Feeling like a caveman...

Re: Beej's Guide to Git

#176

Post by Izkata »

nextaccountic wrote: post #128
kortilla wrote: post #126

Earlier quoted context omitted.

Maybe you’re young, but git is better than all of the other shit before it. Try to come up with something simpler than git, and you’ll end up with something like SVN or CVS that struggled with more than a couple of people working on the same files. Try to make something that is more content aware, and you’ll find out how git got its name in the first place.

Mercurial is simpler than git. It is (or was) just too damn slow

For some people. Back when I only knew how to use subversion, I tried out both git and mercurial, and found mercurial confusing while git clicked immediately.

Unfortunately it's been long enough I don't remember details why, just that it was something with how it handled branches.

Re: Beej's Guide to Git

#177

Post by zelphirkalt »

rblatz wrote: post #59
chasil wrote: post #48

Earlier quoted context omitted.

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…

The devs shouldn’t have access to prod credentials in the first place. That’s the real issue.

Then you need to hire someone else to manage the deployment of services though.

Re: Beej's Guide to Git

#178

Post by globular-toast »

I feel like there is a trick that is missed by many guides (including this one) and most git GUIs I've looked at (with notable exception being magit).

That is, to set your upstream branch to the branch you want to merge into, aka the integration branch. So instead of setting upstream of "feature/foo" to "origin/feature/foo", you would set it to "master" or "origin/master".

This simplifies a lot of things. When you run `git status` it will now tell you how far you have diverged from the integration branch, which is useful. When you run `git rebase` (without any arguments), it will just rebase you on to upstream.

Setting `origin/feature/foo` to upstream is less useful. Developers tend to "own" their branches on the remote too, so it's completely irrelevant to know if you've diverged from it and you'll never want to rebase there.

If you set `push.default` to "current", then `git push` will do what you expect too, namely push `feature/foo` to `origin/feature/foo`.

Why isn't this a more common setup?

Re: Beej's Guide to Git

#179

Post by smiljo »

I'll just chime in with congrats on the new book. I was a huge fan of the Network Programming book that I first read in 2013, and which I still consider as having the best balance of approachability and rigor. Looking forward to checking the new one out. :)

Re: Beej's Guide to Git

#180

Post by zelphirkalt »

billdueber wrote: post #70
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…

Sigh. Another git thread, another pile of posts telling me that if I would _just do the work_ to understand the underlying data structure I could finally allow myself to be swept up in the _overwhelming beauty_ of the something something something. The evidence that the git UI is awful is _overwhelming_. Yes, yes, I’m sure the people that defend it are very very very very smart, and don’t own a TV, and only listen to…

Which brilliant people, who have put in an appropriate amount of time into learning any (D)VCS, are struggling with having a day to day working knowledge/familiarity with git? Can you point to some? Brilliant people is of course a definition question. But one of the defining qualities I would ascribe to a brilliant person, is the ability to quickly grasp concepts and ideas and reason about them. That seems to me to be the core quality one needs to use git, since it requires one to have a mental model, whether actually correct (which I think few people have) or just close enough to be useful.
Post reply on HN