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

221–230 of 273 posts

Re: How to teach Git

#221

Post by oblio »

tux1968 wrote: post #56
Gys wrote: post #9

Earlier quoted context omitted.

For simple projects (like ppl experimenting with git) you will always want to save all changes. So why stage first ?

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.

Re: How to teach Git

#222

Post by jbergens »

I think it is easiest to show a graphical UI like SourceTree or GitKraken when you explain git. GitKraken is my favourite but it costs a little money to use at work.

Re: How to teach Git

#223

Post by oblio »

JoeAltmaier wrote: post #42
jejones3141 wrote: post #40

Earlier quoted context omitted.

I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamics. Why should it be necessary for git?

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.

Re: How to teach Git

#224

Post by oblio »

dave7 wrote: post #215
dahart wrote: post #202

Earlier quoted context omitted.

> Not sure whether your statement is ignorant or insightful I’ll answer that for you. It’s insightful. In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. https://www.chicagotribune.com/classified/automotive/sc-auto... I didn’t understand why you said there will always need to be manuals for vehicles that run on gas... what do you mean?

> In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. At that percentage, the U.S. is a huge outlier however, and accounts for quite some chunk of of worldwide automatic gearbox equipped vehicle production on it's own. The automatic gearbox remains the less popular option worldwide [1], though as you can see they are more popular than they were before…

The real reason that's the case is because most of the rest of the world is much poorer than the US. Also many the people in those other countries don't have to drive as much or as far as people in the US.

At some point it's just Stockholm syndrome (we can only afford manual, everyone has it, so let's at least pretend it's cool!).

Re: How to teach Git

#225

Post by delian66 »

pjc50 wrote: post #96
oblio wrote: post #80

Earlier quoted context omitted.

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

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

Re: How to teach Git

#226

Post by jstimpfle »

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.

git is much more powerful. It gives you control to manipulate the repository like say, a relational database. If svn is enough for you, that's fine.

Re: How to teach Git

#227

Post by oblio »

jstimpfle wrote: post #226
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.

git is much more powerful. It gives you control to manipulate the repository like say, a relational database. If svn is enough for you, that's fine.

> It gives you control to manipulate the repository like say, a relational database

And how many people do that? Not that many. This angle is a bit like the guy who said that he doesn't want Unix file names to be UTF-8 text-only, because he crafted a sort of relational database on top of a Unix FS and by having file names be just text he couldn't do some super niche trickery. I think it was in response to this article: https://dwheeler.com/essays/fixing-unix-linux-filenames.html

> If svn is enough for you, that's fine.

It is, but every job these days forces you to use git. And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server.

Re: How to teach Git

#228

Post by pjc50 »

dahart wrote: post #159
pjc50 wrote: post #98

Earlier quoted context omitted.

> Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes. I did exactly the same diff/tidy/diff workflow when I used p4 and svn, neither of which make a distinction between "working directory" and "staging area".

Right, but p4 & svn have “checkout” which is similar to staging. Staging is part of what we get because we can edit files without having to checkout / open for edit. P4 and svn don’t have a strict commit parentage, which is why you can push commits in those systems in any order. Git’s strict concept of parentage is what makes the staging area so important for keeping your workflow similar to p4 & svn Workflows. Witho…

> without having to checkout / open for edit.

The terminology is a bit different - unless configured with mandatory locking (essential for some workflows) you don't have to open for edit. You just edit stuff and it goes in the "default changelist", roughly equivalent to automatic staging.

> Without a staging area, you’d either have to always fix mistakes with new commits

Mistakes at what point? In the normal svn workflow you can review with svn diff, then when you're happy do svn commit; it's just that there's no local place you're committing to. In both cases there's a critical point, either "svn commit" or "git push".

Re: How to teach Git

#229

Post by pjmlp »

oblio wrote: post #224
dave7 wrote: post #215

Earlier quoted context omitted.

> In the U.S. today, less than 2% of new cars sold are manual now. Automatic gearboxes are well beyond the norm already. At that percentage, the U.S. is a huge outlier however, and accounts for quite some chunk of of worldwide automatic gearbox equipped vehicle production on it's own. The automatic gearbox remains the less popular option worldwide [1], though as you can see they are more popular than they were before…

The real reason that's the case is because most of the rest of the world is much poorer than the US. Also many the people in those other countries don't have to drive as much or as far as people in the US. At some point it's just Stockholm syndrome (we can only afford manual, everyone has it, so let's at least pretend it's cool!).

Indeed, if I could afford semi-automatic gearbox for the same price as manual, including the regular servicing, I would certainly use it.

After all, as GC fan, it does not make much sense to malloc()/free() my gearbox. :)

Re: How to teach Git

#230

Post by karmakaze »

sonnyblarney wrote: post #211
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 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. I can't see something like this would work with code. Hmm interesting... unless we only allow additions and refactorings to working checkpoints.

Post reply on HN