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

261–270 of 273 posts

Re: How to teach Git

#261

Post by tux1968 »

oblio wrote: post #221
tux1968 wrote: post #56

Earlier quoted context omitted.

Not everyone stays a beginner forever, and it's nice to have a tool that doesn't play to the lowest common denominator. It's really not that hard to just do a "git commit -a" if you want to avoid staging.

> Not everyone stays a beginner forever But the vast majority do, or at best become perpetual intermediates ( https://blog.codinghorror.com/defending-perpetual-intermedia... ). 99% of developers out there didn't need a power tool for source control (source control is already quite a power tool many devs can barely handle, even in SVN form...), yet here we are: Git is imposed everywhere, with its horrible UX.

Git's UX isn't that bad if you're only cloning projects to build them locally and keep them updated. The UX only gets really crufty as you use more and more of the features.

Re: How to teach Git

#262

Post by oblio »

delian66 wrote: post #246
oblio wrote: post #234

Earlier quoted context omitted.

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!!!"

No the logic is not circular, and the advice to learn git is a good one. It may seem paradoxical at first to you, but is true (as are many things in this profession). Another paradoxical advice like that, is to learn vim, or emacs, but I digress. Git does not suck - as any other tool it, it just has strenghts and weaknesses (for example working with very large binary assets is its main weakness). The UX of most commo…

You're assuming that I haven't read about Git. I've read a ton about it and its internal data structures. And regarding your digression, I'm a vim user.

Regarding Git, Git does suck. It does the job Linus designed it to do, but that job is not most software engineers across the world need it to do.

In smaller or in corporate shops, Subversion was almost adequate and several bad implementation details, mostly related to branching, led to its demise. So that world needed Subversion++, not Git.

In the FAANG world, there's basically no company that uses Git as-is. It's strength/weaknesses aka tradeoffs aren't good enough for them.

Git won because tech is a popularity contest and people in our domain like to do a lot of virtue signalling ("this tool is hard to use, I use it, so I'm special/cool").

Re: How to teach Git

#263

Post by gerbilly »

It would be so much easier to use git if there was simply a "git undo" that would cleanly undo the last git command (or last n commands would be even better).

Then you could learn more easily via exploration and experimentation.

And I do mean just one command to undo all the things, I know that you can undo a lot of things in git but each command is different, and I know that undoing pushes is hard.

Re: How to teach Git

#264

Post by tome »

bagrow wrote: post #2

Having taught git several times within a data science course I find two concepts especially worth extra time: WHY there is a staging area, and what is the difference between “git” and “github”.

I'm very experienced with git, approaching expert level, and I don't use the staging area. I use

    git commit --verbose --patch
and bypass the staging area entirely. I don't find it helpful.

Re: How to teach Git

#265

Post by tome »

LyndsySimon wrote: post #257
war1025 wrote: post #95

Earlier quoted context omitted.

`git log -p` is my favorite obscure git command. Shows you commit by commit changes. If you specify a path, it limits to only those files. If you do a single file you can do `git log -p --follow ` and it will track the file across moves and renames. Also `git whatchanged` is a super helpful command to see just the list of files that changed in each commit

`git add -p` is also very, very useful. I use it all the time, to the point that I've aliased it to `a`. If you're interested, here's my .gitconfig, including all of my aliases: https://gitlab.com/lyndsysimon/dotfiles/blob/master/git/gitc...

Do you know about `git commit -p`? You might like it even more than `git add -p`.

Re: How to teach Git

#266

Post by tome »

war1025 wrote: post #95
cyborgx7 wrote: post #19

Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".

`git log -p` is my favorite obscure git command. Shows you commit by commit changes. If you specify a path, it limits to only those files. If you do a single file you can do `git log -p --follow ` and it will track the file across moves and renames. Also `git whatchanged` is a super helpful command to see just the list of files that changed in each commit

Yikes, do people consider `git log -p` obscure? I can't live without it!

Re: How to teach Git

#267

Post by jstimpfle »

oblio wrote: post #262
delian66 wrote: post #246

Earlier quoted context omitted.

No the logic is not circular, and the advice to learn git is a good one. It may seem paradoxical at first to you, but is true (as are many things in this profession). Another paradoxical advice like that, is to learn vim, or emacs, but I digress. Git does not suck - as any other tool it, it just has strenghts and weaknesses (for example working with very large binary assets is its main weakness). The UX of most commo…

You're assuming that I haven't read about Git. I've read a ton about it and its internal data structures. And regarding your digression, I'm a vim user. Regarding Git, Git does suck. It does the job Linus designed it to do, but that job is not most software engineers across the world need it to do. In smaller or in corporate shops, Subversion was almost adequate and several bad implementation details, mostly related…

Git won because it is technically superior (IMHO, but I've used most other VCS only sparingly). It's well designed, flexible, and fast. Apart from a command-line interface with some unfortunately named options and a "big file issue" (that has never been a problem for me), I don't think there is anything wrong with it.

What do you think is wrong about it? Or have you only "read a ton" but never used it for a while? In the latter case, I suggest you start with the things I mentioned above, and make good use of "git reflog" as suggested by somebody else. If you know git reflog, "delete tree and clone a fresh copy" is not a thing anymore.

> In the FAANG world, there's basically no company that uses Git as-is. It's strength/weaknesses aka tradeoffs aren't good enough for them.

Do they use svn then?

Re: How to teach Git

#268

Post by Liskni_si »

oblio wrote: post #80
Ajedi32 wrote: post #47

Earlier quoted context omitted.

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Git in many occasions (including when using git log) feels like the designer just threw their hands up and said: "F*ck this shit, make your own UI on top if you want to use this tool!" I don't think Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :( (To the people going: "Oh, it's Open Source!". Sure, so are Mercurial, Fossil, etc.)

> Git [...] feels like the designer [...] said "F*ck this shit, make your own UI on top if you want to use this tool!"

Actually this is exactly what happened back then, which is why many people used https://en.wikipedia.org/wiki/Cogito_(software) as a frontend to git in the early days. That said, I personally find current git UX absolutely fine and I can't imagine being effective without having all those commands like git reset --whatever -p and git rebase --interactive.

Re: How to teach Git

#269

Post by delian66 »

oblio wrote: post #262
delian66 wrote: post #246

Earlier quoted context omitted.

No the logic is not circular, and the advice to learn git is a good one. It may seem paradoxical at first to you, but is true (as are many things in this profession). Another paradoxical advice like that, is to learn vim, or emacs, but I digress. Git does not suck - as any other tool it, it just has strenghts and weaknesses (for example working with very large binary assets is its main weakness). The UX of most commo…

You're assuming that I haven't read about Git. I've read a ton about it and its internal data structures. And regarding your digression, I'm a vim user. Regarding Git, Git does suck. It does the job Linus designed it to do, but that job is not most software engineers across the world need it to do. In smaller or in corporate shops, Subversion was almost adequate and several bad implementation details, mostly related…

My response was to your sarcastic mini dialog above my reply. Do not try to read other peoples minds - it is impossible, and if you really want to, you can simply ask.

>> It does the job Linus designed it to do, but that job is not most software engineers across the world need it to do.

Speak for yourself, you are not most software engineeers.

>>In smaller or in corporate shops, Subversion was almost adequate ...

I have administered SVN profesionally for several years (2005-2007), and was paid to unfuck screwups made by other developers using it (which many times involved restoring from incremental hourly backups done on the SVN server side). Dealing and helping others with their git problems is many times easier.

The FAANG world (which I had to google just now) I imagine has unique requirements (many teams that must coordinate, super gigantic legacy source code base), and the resources to do whatever they want (money, humans to develop and maintain tools and do research). For them, the integration pain from managing multiple smaller repos may be significant. Outside this world however, teams are more independant and the source code size is much much smaller (even for legacy projects).

>> Git won because tech is a popularity contest

You have a point here, but this factor (and network effects in general) is just inertia, and does not explain why git won, given that for example SVN or Perforce had such a head start (in tooling, and in mindshare), and there were other distributed contenders like mercurial and darcs and BitKeeper developed at aproximately the same time, and even earlier. It won in my opinion because it was simply superior tech - faster, good enough and very very easy to get started.

(edited to clean up formatting)

Re: How to teach Git

#270

Post by Double_a_92 »

detaro wrote: post #55
Double_a_92 wrote: post #34

Earlier quoted context omitted.

But why is it an extra step? It's basically just a "longterm" selection of what you want to commit.

Because you not always want to put everything in the box (and if you do, there's a shortcut to do it), and "git commit file1 folder/folder/ * .cpp folder/folder/ * .h ..." for a complex set would be annoying and require you to mentally keep track of it from the beginning. Many beginners will start by always doing "git commit -a" and that's fine, as long as they know there's an alternative once they need it.

My point was more why staging is a special feature that even has a name. You're basically just selecting what changes you want to commit.

What is the usecase where one needs to remember that selection for more than just a few minutes?

Post reply on HN