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

231–240 of 273 posts

Re: How to teach Git

#231

Post by aldanor »

Fellshard wrote: post #129
sokoloff wrote: post #126

Earlier quoted context omitted.

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.

I use Spacemacs ONLY to have access to Magit. And I've successfully converted many non-emacs non-vim folks to use it, all of them love it.

Re: How to teach Git

#232

Post by JoeAltmaier »

oblio wrote: post #223
JoeAltmaier wrote: post #42

Earlier quoted context omitted.

Because every source management tool has a model, and to use it at all you need to know the model. Else you're jabbing buttons and turning dials on a complex machine and the outcome is going to be tragic.

I've used SVN reasonably well without knowing its internal model. I kind of knew a bit about it, I'd never call myself an SVN expert and I still managed to do my job efficiently. Git fails majorly in this regard.

Maybe because git has a different model. Learn that, the objections go away. As the OP attempts.

Re: How to teach Git

#233

Post by rachelmcarmena »

diegoperini wrote: post #218
rachelmcarmena wrote: post #176

Earlier quoted context omitted.

Thanks for the feedback! Right, this is only a help to have a mental map. Only some initial drawings for a mentor or trainer, not for the newbie.

If so, I'd love to see a more elaborate, guide-like version of this model. I've tried a similar approach years ago for teaching and failed spectacularly. Eventually, my peers became comfortable when they got used to the Github Desktop Client. They compared the buttons they click with my terminal commands. We also compared our graph views on Github website to visualize the logic. It's been years and still none of them…

I drew those diagrams after reading Pro Git Book. I missed what appeared at my head, but the entire book is very useful.

For me, command line is freedom. GUIs are very limited.

Don't give up! For my humble experience:

- Try to know your peers, how they work, what difficulties they face when using command line, ...

- "I'm lost" > "git status"

- "How did we solve... ? > "git log"

- "This command is difficult to remember." or "This command makes no sense, I prefer this another name for that action" > "git alias"

Re: How to teach Git

#234

Post by oblio »

JoeAltmaier wrote: post #232
oblio wrote: post #223

Earlier quoted context omitted.

I've used SVN reasonably well without knowing its internal model. I kind of knew a bit about it, I'd never call myself an SVN expert and I still managed to do my job efficiently. Git fails majorly in this regard.

Maybe because git has a different model. Learn that, the objections go away. As the OP attempts.

This logic is kind of circular.

"Git sucks, the UX is atrocious, I don't want to spend half my life learning a tool that shouldn't even need that much hand holding."

"Learn Git!!!"

Re: How to teach Git

#235

Post by vngzs »

deanCommie wrote: post #164
vngzs wrote: post #161

This is missing pointing everyone at a phenomenal ncurses git log viewer: https://github.com/jonas/tig And another great bit: always do `git commit -v` for verbose commit edits. Read your diffs before you commit them.

How can anyone have a project home page without..showing me why I should use the project. Would it have killed Jonas to include a screenshot in the README? I'm not going to install something just because someone says it's good. I have to go multiple links deep to get taken to a Flickr gallery, and even then I'm not sure what is so good about it: https://www.flickr.com/photos/jonasfonseca/sets/721576144707...

You make a good point, and I was similarly disappointed in the homepage, so let me elaborate a bit on why I use it:

1. I want a Git log viewer right in my terminal, that gives me most of the benefits of visualizing a Git log like a "real" GUI.

2. Fast startup. I work in dozens of Git repositories a day, many submodules, etc. To visualize these effectively, I want to type a few characters in my terminal and see the Git history in a digestible way.

3. This essentially `git log --graph --pretty` with the ability to deep-dive into a single commit view of `git log -p` with nothing more than a stroke of the return key. To exit, I hit ESC.

4. Vim-like bindings in a Git viewer. Every visual app that I use daily in my terminal has "roughly Vim" bindings, from Emacs (https://github.com/emacs-evil/evil) to Zsh (bindkey -v) to Tig.

5. This is just as fast to start as `git log --graph --oneline`, but I get a fully interactive view of a Git Repo history. For example, the Linux source [1].

Perhaps I should compile my thoughts and send some README updates and screenshots to help the project.

[1]: https://i.imgur.com/yd7cSd1.jpg

Re: How to teach Git

#236

Post by collyw »

pjmlp wrote: post #92
Sir_Cmpwn wrote: post #66

Earlier quoted context omitted.

It's an engineering tool. You'll be using it all day every day for the rest of your career, the investment is worth it.

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

The difference being that you will likely spend hours of your day thinking in rust, while git should be taking minutes of your day, but often ends up taking hours when you screw up a command and need to restore things to how they were.

Re: How to teach Git

#237

Post by collyw »

Sir_Cmpwn wrote: post #66
collyw wrote: post #64

Earlier quoted context omitted.

That's a lot of reading for a tool that should be making life easier.

It's an engineering tool. You'll be using it all day every day for the rest of your career, the investment is worth it.

You could say the same bout Stack Overflow, but its a lot more intuitive.

Re: How to teach Git

#238

Post by pjc50 »

delian66 wrote: post #225
pjc50 wrote: post #96

Earlier quoted context omitted.

I don't think it was ever really intended for worldwide use by Linus, it was intended to exactly replicate his workflow and his alone. The real responsible party is github; I'm not sure how they came to dominate?

By being much, much, much better than the competition at the time (sourceforge) - github was faster, without ads, used superior vcs. Github also had Octopuss/Octocat as a logo :-) .

Sure, but why github rather than mercurialhub etc? The website has great usability but the git CLI does not. Maybe the github gui was also critical.

Re: How to teach Git

#239

Post by P_I_Staker »

karmakaze wrote: post #230
sonnyblarney wrote: post #211

Earlier quoted context omitted.

This is funny, but in reality it's not. Git is one of the most amazing, powerful tools ever conceived, with one of the must byzantine and ridiculously designed 'interfaces' ever conceived. People confuse the raw power of a tech, with how well it can be feasibly used. Sadly, due to the later issues, git will only ever be a shadow of what it could have been. With all due respect to Linus, who'd be the first to admit he…

I don't think the complexity of git's command options is a UI problem. It results from the basis of its operation. We could change some names, add or remove some concepts to how some of the operations are performed, but there are simply a large number of actions to handle many edge cases. A better solution for prose was to always be merging with live multiple collaborator updates. Conflicts are visible in real-time.…

Yes, I don't really understand all the people trying to "fix git". Git's fine, though the complexity makes it challenging, especially for new users. However the complexity is a direct result of useful features. "Keeping it simple" is great, except when the complexity is needed. I'm hard pressed to name any features I could do without.

Re: How to teach Git

#240

Post by P_I_Staker »

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

Honestly, you just need to try some things. Your reflog is your friend. You'll get the hang of reset/rebase/ect with a little experience. I also think it's worth it to learn a bit more about diff and log.

I have no idea why anyone would want to go back to SVN. If you don't want to use all the features, I understand; by all means, continue to only ever branch -> commit -> push -> create pull request. There's no need to subject the whole team to version control that doesn't work. That's what sold me on git; it's the only version control system that never failed at it's job of letting me track my changes. It doesn't break it's promise to always be there for me.

SVN, centralized systems, and even mercurial to some extent, prevent users from tracking their changes. This leads to questionable workflows (lots of copying directories to "save things"), or even worse, developers just don't track their changes at times. It sounds weird that I have to say this, but I feel that version control systems should be available to track changes 100% of the time. It seems like many of the people who dislike git, don't see the value in this, which I find absolutely baffling. Git means never being scared to create a commit.

Post reply on HN