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

141–150 of 273 posts

Re: How to teach Git

#141

Post by sephoric »

y4mi wrote: post #140
sephoric wrote: post #139

Earlier quoted context omitted.

I was just running into this dichotomy this morning. To test my app Autumn on High Sierra, I had to install it in a VM, so I tried VirtualBox (open source) and Parallels Desktop Lite (in-app purchases). Not only did Parallels have a smoother, cleaner, more modern and easier GUI, VirtualBox just out-right doesn't work when trying to install High Sierra, and I had to find third-party instructions online just to bypass…

You're pinning THAT on opensource? a) VirtualBox is an oracle product. That by itself should be telling. b) High sierra is unsupported as a Guest OS in VirtualBox. You do know what that means, right? c) You seriously complain about the darth of open source virtualization for an OS, which disallows virtualization on anything but apple hardware? ...really? If you want good open source virtualization you'll want to use…

It was the most recent thing I did (literally this morning) so it was fresh in my mind. I'm also not an expert in virtualization solutions given how I haven't needed to use it until now. But this has held true for many, many apps and their open source alternatives. Paid products generally tend to be higher quality than open source, for whatever reason.

Re: How to teach Git

#142

Post by pseudalopex »

aurumpotest wrote: post #36
JediWing wrote: post #21

Earlier quoted context omitted.

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

I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.

Amending the last commit does basically the same thing and records each state in the reflog.

Re: How to teach Git

#143

Post by Already__Taken »

Animats wrote: post #137

From the article: "If you take care the commit history, consider the use of git pull --rebase. Instead of fetch + merge, it consists of fetch + rebase. Your local commits will be replayed and you won’t see the known diamond shape in commit history." No, not how to teach Git. Open source just can't do good user interfaces. The result is almost always a zillion features in search of an architecture. Blender managed to…

Perhaps managing git is finally the business case for VR, Hold my coffee I'm going rebase jumping.

Re: How to teach Git

#144

Post by mrzool »

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. [...]"

Nothing short of sublime. Thanks for sharing.

Re: How to teach Git

#145

Post by smichel17 »

akulbe wrote: post #136
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....)

This is so so fitting, and describe me to a "T" as well. I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.

What can you screw up that requires re-cloning the repo rather than just a reset --hard?

Re: How to teach Git

#146

Post by svat »

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

My recommendations:

* Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc.

* Learn Git Branching: https://learngitbranching.js.org -- in fact I think this should be the UI for Git; wish someone would make that happen (i.e., so that you can point it to any Git repo and get that sort of visualization for it).

Re: How to teach Git

#147

Post by joachimma »

sjburt wrote: post #125
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 v…

100% agree. Once you know what you want the tree to look like it's usually just a matter of making a branch/tag (in case you mess up, and need to start over) and not being afraid of reset, even with the --hard flag.

Re: How to teach Git

#148

Post by romwell »

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. [...]"

This is a kind of very specific, targeted, niche comedy, excellently executed. I only use Git casually, and I can't tell how much of that text couldn't make sense in an actual doc; it all looked real enough at a glance.

Thank you for sharing, this made my week.

Re: How to teach Git

#149

Post by mhd »

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…

TortoiseGIT always required me to check way too many boxes for each individual operation. Took me way longer than on the command line, where you just define one alias and you're good.

My biggest issues with git were when you were working in projects that had other usage patterns. It's a bit like C++, apparently everyone uses different subsets and strategies.

Re: How to teach Git

#150

Post by smichel17 »

url00 wrote: post #69
aurumpotest wrote: post #36

Earlier quoted context omitted.

I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.

This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?

> Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?

Almost. Most often it's:

- Working on solving problem A - Notice problem B - Start to solve problem B - Notice I'm getting distracted from A, and return to finish it. - Want to commit my fix for A, but don't want to lose or forget the partial work on B.

Two different approaches I might take in this situation, depending on whether B is related to A.

1. If they are related (eg, B depends on A), use `add --patch` to commit A, then finish and commit B. 2. If unrelated, use `git stash --patch` to stash B, then commit A, then switch to a different branch to finish B.

Honestly, I see the point of both stash and staging, but not both together. Too many tools for the same job. On my long list of projects to do is a git porcelain that combines some of these concepts (eg, stash and working directory which would be tied to a branch):

- Each branch would have a single stash. - When you check out a new branch, all uncommitted changes are automatically stashed. - If the branch you're switching to has anything stashed, that stash gets popped. - Any current workflow that involves stashing can be replicated by using a branch instead of a stash.

This way, branches can be thought of as "state of the working directory", which is more intuitive with the branching tree model, imo; commits are a snapshot of the repo at that point in time; and the staging area is just a way to choose what should be included in those commits.

Post reply on HN