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

How to teach Git

rachelcarmena.github.io

Post reply on HN
Print view View original

121–130 of 273 posts

Re: How to teach Git

#121

Post by pjmlp »

mcguire wrote: post #117
Sir_Cmpwn wrote: post #94

Earlier quoted context omitted.

How about now :) Rust and C++ are complicated languages, and that's bad. But git isn't complicated. Git is a handful of simple ideas composed in interesting ways. It looks complicated because there's a lot of porcelain commands with a lot of options, but all of them are just manipulating the same simple internals which, once understood, are clear and intuitive.

Many people would disagree---the permutation of simple ideas gets...less simple quickly. On the other hand, I've used ClearCase. (Do not use ClearCase.)

That is the thing, dealing with git issues brings back flashbacks of using Clearcase views on UNIX.

Re: How to teach Git

#122

Post by pjmlp »

Sir_Cmpwn wrote: post #94
pjmlp wrote: post #92

Earlier quoted context omitted.

I will save this answer for when anyone complaints about C++ or Rust being complex languages.

How about now :) Rust and C++ are complicated languages, and that's bad. But git isn't complicated. Git is a handful of simple ideas composed in interesting ways. It looks complicated because there's a lot of porcelain commands with a lot of options, but all of them are just manipulating the same simple internals which, once understood, are clear and intuitive.

I see you got my devil's advocate gist. :)

Thing is, dealing with git feels like being in the early 2000's using Clearcase views.

Re: How to teach Git

#123

Post by NoodleIncident »

JediWing wrote: post #21
radarsat1 wrote: post #4

Earlier quoted context omitted.

> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?

So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…

Committing isn't a commitment. After making the first commit, you can use the `git stash` command to put the rest of your changes aside, and go through the normal test->amend loop until you're happy with that first commit. Then you just retrieve your other changes from the stash to make your second commit.

It's also possible to do this without the stash command, by making both commits right away, and testing them later. However, that would involve rebasing(?) your second commit on top of any changes you end up making to your first commit, so using the stash makes more sense to me personally.

Re: How to teach Git

#124

Post by mcguire »

mdpopescu wrote: post #81

1. Install TortoiseGit 2. Use Visual Studio to commit (it automatically does "git add" with the new files you added to the project - I always forget to do this manually) 3. Use TortoiseGit to do "git push", because Visual Studio has a problem with ssh keys (or at least had a while ago and I didn't bother to check since) 4. When something breaks (and it will), google like crazy until you find a solution There. I never…

"...it automatically does "git add" with the new files you added to the project..."

Uh, yeah. You don't add random temporary files (notes, temporary testing data, the florist's phone number that you'll need after the meeting you're already late for) to your projects?

Re: How to teach Git

#125

Post by sjburt »

iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want.

And then git fetch/push/pull are mostly about copying parts of that graph from one place to another.

After that, it's mostly a question of what workflow you want and that becomes much more than a git question because git works for a variety of workflows, and many of the features of git are really only relevant for certain flows.

Re: How to teach Git

#126

Post by sokoloff »

iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

If you're an emacs user (and maybe even if you're not), try the magit package.

That taught me in a few weeks of usage more git 102 and 201 type functionality than a year of using only the basics did.

Re: How to teach Git

#127

Post by wickchuck »

iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

SublimeMerge is also a wonderful tool. Been using that since it came out and has helped tremendously with difficult merges. It's lightning quick as well.

Similar to magit - Sublime Text also has SublimeGit, not as fast as SublimeMerge.

Visual Studio Code built in git functionality is also nice.

Re: How to teach Git

#128

Post by mdpopescu »

mcguire wrote: post #124
mdpopescu wrote: post #81

1. Install TortoiseGit 2. Use Visual Studio to commit (it automatically does "git add" with the new files you added to the project - I always forget to do this manually) 3. Use TortoiseGit to do "git push", because Visual Studio has a problem with ssh keys (or at least had a while ago and I didn't bother to check since) 4. When something breaks (and it will), google like crazy until you find a solution There. I never…

" ...it automatically does "git add" with the new files you added to the project... " Uh, yeah. You don't add random temporary files (notes, temporary testing data, the florist's phone number that you'll need after the meeting you're already late for) to your projects?

I want the notes in git. I never added temporary testing data (or the florist's phone number) to a project unless it was in code.

Re: How to teach Git

#129

Post by Fellshard »

sokoloff wrote: post #126
iheartpotatoes wrote: post #106

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

If you're an emacs user (and maybe even if you're not), try the magit package. That taught me in a few weeks of usage more git 102 and 201 type functionality than a year of using only the basics did.

As a new emacs / spacemacs user, I bounced off magit hard. Too many weird things going on, hard to tell what I can do.

A couple months later, and a bit more experience with how emacs structures things, and I've returned to Magit and _love_ it. It just feels natural to hop around in for standard tasks. Certainly a good replacement for other porcelain UIs I'd normally use.

Re: How to teach Git

#130

Post by arduinomancer »

ahartmetz wrote: post #60

And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"

That's hilarious
Post reply on HN