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

241–250 of 273 posts

Re: How to teach Git

#241

Post by maceurt »

Derbasti wrote: post #217

I have taught git for university classes for some years. To be honest, git is a mess. It is conceptually not that hard, but the nomenclature is inconsistent and dangerously ambiguous (quick, what is the difference between reset, rebase, revert, and checkout?). The most effective work flow I have found so far, is teaching only status/clone/pull/add/commit/push. Show them explicitly what happens normally, what happens…

I don't know if this is true. For me personally I have had to use git for a lot of different projects, but I still don't understand anything besides commit, push, pull, add, and force-push (lol). In my experience you can get away with just learning those commands, but I still don't feel comfortable with git.

Re: How to teach Git

#242

Post by dahart »

pjc50 wrote: post #228
dahart wrote: post #159

Earlier quoted context omitted.

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

> unless configured with mandatory locking ... you don’t have to open for edit.

I’d guess you’re learning toward talking about svn, which I don’t remember very well, and I am leaning towward talking about p4, which always does mandatory locking.

You’re right the terminology is different between these different systems, I’m just pointing out that the git staging area has what you can think of as some equivalences in the other systems. Or, you can think of it as tradeoffs. Either way, the git staging area is something that helps you pretend like you’re using svn or p4 in the sense that it helps support editing multiple changes at the same time before pushing them to a server.

> Mistakes at what point?

With git I’m referring to mistakes between commit and push. But there’s a philosophical difference here that I glossed over. With git it’s easier to commit early and often than it is with svn or p4. With svn & p4 it’s easier to lose your work because version control doesn’t know anything about it before you push. If I make micro-commits, which I want and I like, then I put more “mistakes” along the way into my local history, and I can use the staging area to clean everything up before I push. With svn & p4, you make those mistakes and do the cleanup without ever telling the version control, and you run a greater risk of losing that work while you do the cleanup.

Re: How to teach Git

#243

Post by delian66 »

pjc50 wrote: post #238
delian66 wrote: post #225

Earlier quoted context omitted.

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.

Yes, the gui was good (and it still is, or may be I am too familiar with it at this point, I do not know).

Another factor is that git was always FAST, and the most common operations (init, log, status, commit, checkout, push, pull) are not that complicated as people make them to be, so you can very easily start to use it for new local projects, and continue without installing additional plugins, unlike mercurial ... And at some point, when you wanted a colaboration hub or just a public remote repo, you just pushed your code to github.

Re: How to teach Git

#244

Post by delian66 »

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

What an absurd statement: "Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :(" !

Who are you exactly to judge people like that, oh failed incarnation of a tibetan Lama ???

He does not need an excuse to make a tool that has proven very useful to many (including me). In fact, I am grateful, that he chose to make it and publish it.

Re: How to teach Git

#245

Post by sonnyblarney »

P_I_Staker wrote: post #239
karmakaze wrote: post #230

Earlier quoted context omitted.

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.

There are two problems: one of inherent complexity, one of UI.

First - the UI is a mess, and that should have been fixed. It would make a big difference.

Second - is the inherent complexity. That's a good point, but I feel many things could be hidden or obfuscated.

Most poignantly, Git does something that most of us do not need: it was designed to work as a 'completely distributed system', i.e. for open source.

Almost none of us do that. 95% of uses cases related to you and I working collaboratively, on a project together.

The need to have repos which are essentially totally distinct from one another is a huge source of complexity and it simply doesn't need to exist in most cases.

So Git is basically an 'admin level tool' that is commonly used in scenarios for which it wasn't meant to be used, with a confusing interface.

It's costing a lot of time and money and headaches, I do believe someone may come along eventually and fix it.

This thread is essentially evidence of this - see how many people have difficult teaching what should essentially be a simple thing in most cases.

Way too many very smart people still spend too much time clustering around in git.

Re: How to teach Git

#246

Post by delian66 »

oblio wrote: post #234
JoeAltmaier wrote: post #232

Earlier quoted context omitted.

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

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 common git CLI operations is clean actually, as they are fast, and you do not need many arcane options (although they are there, and are documented well, for people who read...).

If you screw up something, you just use the reflog to fix the state of your repo in most cases. Even if you can not (or do not want to), the troubleshooting is still easy - you can always do a fresh clone from your remote repository in a new folder and copy what you want there.

Re: How to teach Git

#247

Post by fiblit »

sonnyblarney wrote: post #245
P_I_Staker wrote: post #239

Earlier quoted context omitted.

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.

There are two problems: one of inherent complexity, one of UI. First - the UI is a mess, and that should have been fixed. It would make a big difference. Second - is the inherent complexity. That's a good point, but I feel many things could be hidden or obfuscated. Most poignantly, Git does something that most of us do not need: it was designed to work as a 'completely distributed system', i.e. for open source. Almos…

Ever used a centralized VCS, such as SVN? That seems to be what you want? A distributed VCS is extremely useful, for mine and many others' uses, however.

Re: How to teach Git

#248

Post by recursive »

ezrast wrote: post #183
recursive wrote: post #154

Earlier quoted context omitted.

Yes, it requires more explanation than that. I've used git for years, and never really understood why staging is even a thing. Your example is an implementation of the box-putting algorithm, but it doesn't need to be mirrored in the put-box CLI. put-close-box file1 file2 This command could encompass all the putting and closing. Since you only close boxes when you are done putting things in it, I don't see a need or p…

That's not convenient when you're putting things into the box piecemeal, especially with `git add -p`. A thing I do frequently is to run `git diff`, scan through it, and add files (or parts of files) one by one in a second terminal. Then I do a final review of the staging area (with `git diff --cached`) to make sure it only has the changes I want and commit. I'm the sole devops engineer at my company and my workflow…

To me, that ought to be a concern of the "porcelain", although no one uses that word anymore. CLI is particularly bad at certain types of interaction. So to compensate, a mitigation is moved into the underlying model of git. That mitigation is staging. The inconvenience of "piecemeal adding" could have easily been addressed in the UI layer using a more suitable presentation, rather than forcing all clients to follow the stage/commit dichotomy.

Re: How to teach Git

#249

Post by krupan »

P_I_Staker wrote: post #240
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 t…

"and even mercurial to some extent, prevent users from tracking their changes"

False. Stop spreading misinformation about Mercurial.

"Git means never being scared to create a commit."

This is indeed one of the biggest benefits of DVCS tools, including git and mercurial.

Re: How to teach Git

#250

Post by probinso »

Derbasti wrote: post #217

I have taught git for university classes for some years. To be honest, git is a mess. It is conceptually not that hard, but the nomenclature is inconsistent and dangerously ambiguous (quick, what is the difference between reset, rebase, revert, and checkout?). The most effective work flow I have found so far, is teaching only status/clone/pull/add/commit/push. Show them explicitly what happens normally, what happens…

I found that running workshops was the most effective way to teach git. I wrote a set of tools against the github api to spin-up and manage a large number of repositories and students in a way that would result in merge conflicts (and doesn't require knowledge of any programming language).

https://github.com/probinso/ABC

Post reply on HN