One-Percenters Close to Surpassing Wealth of U.S. Middle Class - <AUTHOR> https://www.bloomberg.com/news/articles/2019-11-09/one-percenters-close-to-surpassing-wealth-of-u-s-middle-class <comment><USER2> If past history is anything to go by they will support "moderate and conservative" status quo politicians until the point where the people have given up on them and started seeking more radical change - from ever more extreme versions of the right and the left.

At that point the ultrawealthy will seek to form an alliance with the growing popularity of the far right and seek to annihilate the left. This is simple self preservation. The far left will, after all, seek to destroy billionaires whereas the far right will seek out easier targets who look/sound different (muslims, immigrants, jews, gays, people of color, etc.).

The point where things start to become terrifying will be the point where billionaires give up on status quo politicians and start to throw their weight behind the far right. That's when the far right switch from being a bunch of racist, loser skinhead misfits into a well funded, slick and violent ultranationalist nightmare.

As far as I can tell, the current weimaresque neoliberal age is sputtering to a close and we're seeing the beginnings of this pattern re-emerging.

<comment><USER3> > At that point the ultrawealthy will seek to form an alliance with the > growing popularity of the far right and seek to annihilate the left.

That's a weird characterization, given that the trend has been in the opposite direction: [https://www.vox.com/polyarchy/2016/6/3/11843780/democrats- we...](https://www.vox.com/polyarchy/2016/6/3/11843780/democrats-wealthy- party)

Also, frankly, the attempt to make it seem like the "left" has a monopoly on "people of color" and "immigrants" is offensive. Trump got almost 30% of the Hispanic vote, and it's not because of the lovely things he said about Hispanic people. Abbott got over 40% of the Hispanic vote in Texas.

The idea that billionaires are going to form a coalition with nazis to oppress "people of color" is a leftist fever dream.

<comment><USER4> Why _did_ Trump get 30% of the Hispanic vote? In South Florida, Hispanics love him (yet he can famously be heard talking about building a wall, which would have kept them and their family out)

<comment><USER5> Hispanics in South Florida (or their ancestors) came by sea, not land. A wall wouldn't have kept them out.

Despite US culture's obsession with slotting people into racial categories like "Hispanic", Cubans in Florida actually have very little in common with Mexicans and Mexican-Americans in California, Texas and the Southwest.

<comment><USER4> Excuse my ignorance but, if South Florida had a wall, couldn't people _not_ get in by sea? I know Trump was not discussing adding a wall to anything other than the southern border. I just felt that the premise of "I want to keep Hispanics from entering the country" would apply to people coming by sea as well.

<comment><USER5> Are you asking if, theoretically, a wall could be built in the sea to keep Cubans from reaching Florida?

Whether that's the case or not, I'm not sure how it's relevant to the discussion of who Florida Cubans align with politically, since it hasn't been proposed or discussed by Trump or anyone else.

</comment></comment></comment></comment></comment></comment><comment><USER6> Someone with a beter insight: does that mean that I somehow is worse or better off? From where I stand, I hear/read a lot of criticism, but I've yet to see that Bill Gates, Jeff Bezos, e.g., is going into my account and then steal my money which results me being in a worse position.

I am of the opinion that if we everyday feel resentment towards those who have more, that we are in itself creating a lesser condition for ourself. Whether that be mental illness, hate, or worse.

Your thoughts?

<comment><USER7> The idea is that one person gets a great deal of wealth from the creation of something that they were the most important in that creation. We would all agree that what Gates and Bezos acomplished was laudable and needs to be encouraged in society. However, in a different era Arthur Sloan (GM) or Henry Ford actually ended up with a lower percentage of the wealth of their companies. More of that wealth was distributed as opposed to concentrated in a founder or CEO. Did that discourage their excellence? I don't think so. Did it make a healthier society? I would argue yes.

<comment><USER8> Did the wealth of car companies go to labor? Or did the wealth go to the venture capitalists (or whatever the venture capital equivalents of the day were)?

Because those are very different situations.

<comment><USER9> The real wealth that car companies created went to consumers in form of consumer surplus.

The automobile used to be a toy for millionaires, now even (American) minimum- wage workers can travel daily in comfortable, individual, climate-controlled vehicles capable of incredible speeds.

I would pay $100k for a ten-year-old Civic but I don't have to because the car companies work hard and compete with each other and have driven down costs and prices to the bare minimum.

Same for many of todays billionaires / huge corporations. They're generally not stealing from us, but creating enormous wealth for all of us in the form of consumer surplus with their desirable goods and services.

<comment><USER10> But are the billionaires the ones actually responsible for creating all that value? Is Bezos actually responsible for 10 000x the value of what Amazon produces than a worker? If Bezos didn't exist, there would be another "Bezos". He just happened to be there at the right time and do the right things. We discount all the effects that luck and society play in making a "Bezos". The company is what is providing that huge amount of value, not the person.

<comment><USER11> You have to apply your argument to yourself, which is "are you responsible for creating any of the value you create?" If you didn't exist there would be another you, so luck and society made you. But you know that is not true. You are where you are, and you can step away at any time.

</comment></comment></comment></comment></comment></comment><comment><USER12> Why do such discussions on HN always end in some crude left vs. right fights?

Later addition because most answers say that this is normal for politics:

Usually on HN for other topics such a primitive black and white thinking is in the minority and will be laughed about or just ignored. Why not if it comes to politics?

<comment><USER13> The same is happening a lot in the media as well. The first step is to project the complex problem into 2D space. Then retrofit the arguments so that they fit the narrative. I suspect that somebody who consumes a lot of that type of media will have their reasoning process being influenced.

The engineering approach would try and decompose the problem without judgement. Then explore the tree of possibilities, apply weights on all the possible outcomes and then take the best possible route, knowing full well that an ideal doesn't exist.

I am sure it's possible to apply many more lenses to a problem, each of then bringing more richness and understanding to the world.

<comment><USER14> >The engineering approach would try and decompose the problem without judgement.

The whole point of the existence of poilitical economy and sociology is th at this kind of decomposition is very hard, if not impossible - without judgement implies that those who practice this kind of thinking, or engineering, are able to adopt a view from nowhere, but the fact is that these people belong to groups in society, they are personally affected by the outcome, and absolutely already have pre-existing interests. Furthermore, you automatically figure this as a kind of balancing game with weights, but this implies that the weighting _can_ be done (how do you weigh two qualitative choices?) and further the utilitarian view that all that matters is the maximum weight. Both of these problems are why there is intense debate in moral theory regarding instrumental reason and consequentialism.

<comment><USER13> Weighting is certainly a difficult exercise. Even for engineers where the problems are more concrete, it often relies on building some sort of shared vision that is used to infer a future prediction. In fact most of the disagreements I see is when two engineers have a different view of the future. For sure, both quantitative and qualitative approaches are necessary to build a proper model.

Anyways, my point was that by looking at every argument by first placing it on a left vs right scale removes the interesting nuances that could be discussed. I don't know that the engineering approach is necessarily the best tool to solve social inequalities as this is not my topic at all.

</comment></comment></comment></comment><comment><USER15> There is no greater class solidarity than that of the ruling class.

<comment><USER16> Quite. We see news articles on a daily basis proclaiming the solidarity of the US Congress.

Really this is such an unsubstantiated comment. No one carries a card for being a member of the "ruling class". Instead people making this argument simply cherry-pick from diverse groups for their purposes and claim they all work/live/think the same: politicians, the rich, foreign interests, lobbyists, youth activists, corporations, media, far right fringe, etc.

<comment><USER17> Congress may get into petty squabbles over issues like farm subsidies or trans rights, but they are generally agreed on the status quo of the current United States economy. There is bipartisan support for unfettered corporate control over wide sectors of the economy and public resources.

I'm not saying that both sides are the same here. I'm saying that what Chuck Schumer wants for his class and what Mitch McConnell does are broadly the same. Chuck might pay lip service to his constituents by opposing tax increases, but at the end of the day both would still vote to increase the defense budget, vote against Medicare-for-All, vote against expansion of welfare and entitlements, vote against most things that would make life easier for the struggling majority in this country.

The exceptions, like Sanders, Warren, Ocasio-Cortez, etc., are just that, exceptions. We often forget just how ridiculous and absurd both Sanders and his positions were viewed in 2015 when he first entered the race.

</comment></comment></comment><comment><USER18> The article seems to indicate that those gains are all paper money due to the huge inflation in the stock market. On paper they look richer, but they can't do much with their "money" anyway. I think a more rational measure of inequality is through the possession of "important" assets like real estate, lands, power (political influence, ...). Of course the real problem comes when the lower and middle class sells their real wealth for stocks at the top, and the 1 percenters sell them their paper gains for "important" assets.

<comment><USER19> Yeah housing prices in a lot of areas have barely recovered to the last peak from 12 years ago (and housing equity has traditionally comprised most of the "middle class"'s wealth), while stocks are like at least double (not even including dividends).

<comment><USER20> If you're focusing on houses, you're looking in the wrong place. Look at rental property values, particularly in cities but even suburban areas.

</comment></comment></comment><comment><USER21> Sigh. Journalists have forgotten how to talk about class.

"One-percenter" isn't a real thing. It's just math. There is absolutely nothing tying the 'one-percenter' class together. They're not banding together to make it so their kids have a straight run into the Ivy League. They're not trying to stay politically dominant by passing poll taxes.

One-percenters aren't doing that. The upper class is. And there's plenty of "one-percenters" that aren't part of the upper class, most notably tech workers.

Social classes each have their own institutions of which they dominate. They have industry segments in which they maintain presence. But apparently we can't talk about that anymore. Sadly it's probably less to do with anything more nefarious than the gutting of funding for journalism, so all the stories are getting lazier and lazier.

<comment><USER22> > And there's plenty of "one-percenters" that aren't part of the upper class, > most notably tech workers.

You're going to have to back that assertion up.

<comment><USER23> Well, according to income charts, thats me.

Im most certainly not upper class, as I can't even afford to buy department store clothes or go out to eat more than once a week.

My expenses, due to my location, education, medical status and job, eat up a lot of my income. I'm VERY thrifty and am about 75% over the poverty line after job/education expenses. Throw in medical, transportation and the ridiculous housing costs and I can't even afford mcdonalds for breakfast.

<comment><USER24> Classes by definition are about wealth

If you're unable to manage your money it's your fault, but you're not working class

<comment><USER25> Income is not wealth.

<comment><USER26> [https://youtu.be/bZWeFtgEAEk?t=41](https://youtu.be/bZWeFtgEAEk?t=41)

Here's the difference between rich and wealthy. Shaq, is rich, the white guy that signs his check is wealthy.

Rich is something you can lose over the summer in Vegas with a drug habit.

<comment><USER22> Shaquille O'Neill, with an estimated net worth of approximately 400 million dollars, is wealthy.

<comment><USER26> It's an old video, def is now wealthy.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> What's better? Next year the 1% grow 20% wealth and the rest grows 5%? Or next year the 1% lose 20% of their wealth while the rest lose 5% of their wealth?

In option 1, the pie is growing for all, but for the rich faster than for the rest. In option 2, all of us are poorer, but we are more equal.

I would prefer option 1, while I believe many on the left would prefer option 2 given the proposals to enact socialism and seize property from those who have it.

<comment><USER7> Inequality of resources ultimately destroys equality of opportunity. If some cannot afford to send their kids to an acceptable elementary school (no joke in parts of the US) and some can afford to buy a college, meritocracy is a myth.

If the choice were between no growth + equality and growth + no equality I too would choose growth. However, the period of the fastest economic growth in the US (1940-1950s) featured much higher taxes, much lower ratios between the highest and lowest paid, and much more economic equality. The idea that equality and growth are incompatible is unsupported dogma.

<comment><USER28> >However, the period of the fastest economic growth in the US (1940-1950s) featured much higher taxes, much lower ratios between the highest and lowest paid, and much more economic equality.

This is a much parroted line, but it needs to be pointed out just how exceptional of a time period the 1940s-1950s were in the history of the world. The US at this time was literally the only functioning industrialized economy left on earth. All of Europe, Russia, and Japan were left in ruins. China hadn't even remotely begun to industrialize. Southeast Asia, Africa, and Latin America's GDPs were totally negligible. If you wanted to buy _anything_ beyond raw materials, it came from the US.

We live in a fundamentally different world now, where we must compete in a fully globalized economy. The US has succeeded at competing in high paid, high technology sectors, which by their nature have contributed to the inequality of incomes we now see.

<comment><USER29> > The US at this time was literally the only functioning industrialized > economy left on earth. If you wanted to buy anything beyond raw materials, > it came from the US.

Except for Australia, as manufacturing in Australia was still a thing then. And there were a few other developed nations that survived the war with their economies reasonably intact.

The USA wasn't a total global monopoly. Nor was international trade as common as it is now .

</comment></comment></comment></comment><comment><USER30> The middle class (and lower class) has suffered tremendously from the lower cost of labor abroad and the ability to cheaply import goods and services. The upper class has benefited tremendously from the same.

Another thing that has decimated the middle class is the general collapse of family. Divorce is the greatest family wealth destroyer in America.

People who care especially about jobs for the lower and middle classes support trade and immigration restriction politics. This is exactly why certain midwest states handed Trump the election in 2016, whatever imperfect good they got from that. I've been to these places. People in rust belt towns with closed factories did not think that the Democrats were going to bring the jobs back.

If free trade improves the overall economy by making the very rich slightly wealthier, and destroying the jobs of everyone else, it is obviously not an unalloyed good, and perhaps not in the interests of most people. Similarly with mass immigration.

<comment><USER31> >The middle class (and lower class) has suffered tremendously from the lower cost of labor abroad and the ability to cheaply import goods and services.

The middle class in China and India (which barely existed a few decades ago) has profited tremendously from this. It's a natural equalisation: why does a worker in America deserve a better standard of living than a worker in Indian or China when the latter is willing to work so much harder to pull his family out of abject, mud-hut poverty?

<comment><USER30> There are other groups that I would bankrupt first to help the third world than the American middle class, if that's what it takes.

</comment></comment></comment><comment><USER32> Interesting that pension assets make up such a large portion of the 90-99% bracket. That must include self built retirement accounts, IRAs, 401ks, 403bs, etc., and not just traditional defined benefit pensions

</comment><comment><USER33> Would be curious to know what the wealth level is at for the different percentiles mentioned. e.g. 50% 90% 99% 99.9%. I can't find anything recent.

<comment><USER34> [https://www.ssa.gov/cgi-bin/netcomp.cgi?year=2018](https://www.ssa.gov/cgi- bin/netcomp.cgi?year=2018)

</comment></comment><comment><USER35> In analyses like these I always have to ask, are they counting the pension funds?

</comment><comment><USER36> What's the income that one needs to be inside the "one percenters"?

<comment><USER37> For income it is about $720,000[1]

For wealth it is $10,000,000[2]

[1] [https://www.investopedia.com/personal-finance/how-much- incom...](https://www.investopedia.com/personal-finance/how-much-income-puts- you-top-1-5-10/)

[2] [https://dqydj.com/net-worth-brackets-wealth-brackets-one- per...](https://dqydj.com/net-worth-brackets-wealth-brackets-one-percent/)

</comment></comment><comment><USER38> Why is there an obsession over the 1% when the 0.0000001% (8 men) owns as much as the bottom 50% of the world? [https://www.oxfam.org/en/press- releases/just-8-men-own-same-...](https://www.oxfam.org/en/press- releases/just-8-men-own-same-wealth-half-world)

EDIT: correct headline

<comment><USER39> 1) The analysis in that report is very bad.

[https://www.bloomberg.com/opinion/articles/2019-01-24/oxfam-...](https://www.bloomberg.com/opinion/articles/2019-01-24/oxfam- claim-of-soaring-wealth-inequality-relies-on-shaky-analysis)

2) You have taken the bad analysis and made it even worse. The headline says 8 men own as much as half the world (as much as the bottom 50%). That does NOT mean they own half the world. Far far far from it. (EDIT: you fixed this part with your edit)

<comment><USER38> What about this link (2019): [https://www.cnn.com/2019/01/20/business/oxfam- billionaires-d...](https://www.cnn.com/2019/01/20/business/oxfam-billionaires- davos/index.html)

So top 26 instead of top 8.

Anyway my point is that all these news article lump the top 1% together even though you can make similar headlines about just the top 0.1%, 0.01%, 0.001%, 0.0001%, 0.00001%, 0.000001%.

<comment><USER39> That's the same Oxfam report from another year. They keep saying the same wrong stuff every year.

Whatever your point is, it's not very meaningful if it's supported by faulty evidence or reasoning.

<comment><USER38> Does it materially change the conclusion whether it's 8, 26, 100, or 1000 billionares?

I am saying the top 1% is 77 million people and you can narrow that group down by _a lot_ and still make the same headline of top X surpasses wealth of bottom Y.

<comment><USER39> Ya, I know you're saying that. But everything specific you've stated so far has been false.

Keep in mind that the top 1% have a combined wealth of about 35 trillion. The combined wealth of all US billionaires is only 10% or so of that.

So the core idea that you seem to be trying to express, that the billionaires have it all, is just not accurate.

<comment><USER40> That's not the core idea he/she is expressing. The core idea is that selecting a certain wealth level or percentile to be outraged about is wholly arbitrary. And therefore it doesn't make sense to cherry pick the 1%, and if the vague logic of what constitutes inappropriate wealth is to be used, it would make more sense to look at the billionaires than the 1%. The billionaires have incredible wealth per capita compared to the 1%, most of whom still have to actively plan for retirement and worry about financial security.

Personally I think the focus on the 1% is a bad tactic since it targets people who are everywhere all around us, whom their friends know to be talented or hard working or to have undertaken the stress of operating a small business or whatever. For that reason it does and will continue to come off as inappropriate/unfair/immature to demonize the 1%, and hell probably even the 0.1%. This is why Occupy Wall Street was so easily dismissed.

<comment><USER39> 1) Personally I think that you have it exactly backwards. If you look at Western Europe and all the social services provided there, they don't do it by going after billionaire's money because there simply aren't enough of them. They do it by having significantly higher taxes on most above average incomes.

In the US, when we focus the discussion on the ultra rich and move it away from the merely well to do, we take the discussion away from what has to happen if we want things like single payer health care or vastly cheaper college education.

2) Also, for the record this is a little questionable:

 _compared to the 1%, most of whom still have to actively plan for retirement and worry about financial security_

To be in the 1% of wealth you've got to have over 10 million dollars. If you've got that much on hand and you're all that worried about retirement you either can't do math or your idea of a comfortable retirement is quite lavish.

<comment><USER41> We don't just take the discussion away from what it will take to get what we want; we also either:

(a) implicitly constrain our notion of what is possible ("what is possible is what we can offset with a redistributive pay-for"), _or_

(b) in reckoning with the fact that billionaires can't (for instance) pay for single-payer health care, force ourselves to reject entirely the notion of accounting and economics (see MMT, which is a serious idea in academia but finds an entirely unserious expression in public policy).

Europe doesn't seem to have this problem; they seem simply to decide that everyone needs guaranteed-issue, subsidized, affordable health insurance (or a single payer), and then tax the middle class to pay for it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> One thing being a programmer has taught me is to understand a problem if you really want to fix it. Maybe one day I will do a deep dive in politics and economics. Then I could have real answers and better/more-informed discussions.

Looking at this now though I think, okay, there's more of us than them. Let's just take it and figure out how to redistribute it. But I know most of them are probably innocent and goood people. I suspect the real problem is our failed government. Does anyone have any idea how we can solve wealth inequality? Will it happen or will we keep slipping?

<comment><USER43> You just need to tweak the system to make accumulation a bit harder. Currently money attracts more money. It's not rocket science to implement a plan that means that any entity with lots of money needs to work a little harder to retain it and grow.

Rich people always say they are smarter and deserve the money. Well that's fine. They'll continue being smarter and continue being rich but it'll just be a bit harder for them. Seems fair to me.

P.S. Yes I think a small wealth tax is a good start. Little tweaks

<comment><USER44> Rich people aren't smarter as a whole - they may be slightly smarter than average but much luckier, which is what the literature supports: [https://hbr.org/2015/11/are-successful-ceos-just- lucky](https://hbr.org/2015/11/are-successful-ceos-just-lucky)

What they do have is more luck, either by their location of birth or parentage, being in the right place at the right time, and so on. There's no outsized intrinsic merit to the wealthy, as much as members of that class would prefer to believe.

Taxing the lucky to spread the luck around seems like a reasonable and commendable approach.

<comment><USER40> That HBR article is poorly written and doesn't support your comment. An example of poor quality - it mentions taller men are more likely to be CEOs, which implies causality but it offers no data or statistical analysis to support such a claim. A simple correlation may warrant investigation into causality but isn't causal itself. Additionally that entire article is about CEOs and not "the rich", which are two different categories. The CEO of a well-funded startup isn't necessarily rich, for example.

Most wealthy people I've met may have had occasional luck but they've also had bad luck. But they are smarter, work harder (more intensely and longer hours), and put themselves in positions to encounter luck/opportunity with high frequency. By and large I've observed it to be a result of their innate traits and active decision making.

This recent cultural obsession with claiming that merit isn't real and that meritocracies are a myth is itself a feel-good myth with little basis in reality. Every piece I've read with such claims either rests on dubious statistics or pontificates endlessly to ultimately state personal opinion.

<comment><USER44> Says the throwaway who is ignorant of the etymology of "meritocracy"

</comment></comment></comment></comment></comment><comment><USER45> Some links on wealth inequality that I've read/watched recently:

\- _Income Inequality and the Taste for Revolution_

[https://www.jstor.org/stable/10.1086/426881](https://www.jstor.org/stable/10.1086/426881)

(Study based on global survey data and GINI coefficients.)

\- _Robert Reich: Everything You Need to Know About the New Economy_

[https://www.youtube.com/watch?v=fMmH_2EYohQ](https://www.youtube.com/watch?v=fMmH_2EYohQ)

\- _The dirty secret of capitalism -- and a new way forward | Nick Hanauer_

[https://www.youtube.com/watch?v=th3KE_H27bs](https://www.youtube.com/watch?v=th3KE_H27bs)

\- _Why Free College Could Increase Inequality_

[https://www.thirdway.org/memo/why-free-college-could- increas...](https://www.thirdway.org/memo/why-free-college-could-increase- inequality)

</comment><comment><USER46> Un-paywalled version: [https://outline.com/2DXFqv](https://outline.com/2DXFqv)

</comment><comment><USER47> elizabeth warren 2020

</comment><comment><USER48> QE/ZIRP over fiscal policy.

Obama, who during his first term could have chosen fiscal policy and tax policy, instead decided to take on health care. Obamacare also weakened the middle class.

<comment><USER49> >Obamacare also weakened the middle class.

Care to elaborate?

<comment><USER48> skyrocketting premiums

[https://www.washingtonpost.com/national/health- science/aca-p...](https://www.washingtonpost.com/national/health-science/aca- premiums-rising-beyond-reach-of-older-middle-class- consumers/2019/03/04/bdd07d9e-3e9a-11e9-922c-64d6b7840b82_story.html)

[https://nypost.com/2017/09/06/obamacare-is-making-the- middle...](https://nypost.com/2017/09/06/obamacare-is-making-the-middle-class- the-new-uninsured/)

<comment><USER50> A more accurate statement would be forcing health "insurance" companies to accept sick people and therefore pay for their care, and limiting the ration of highest premium to lowest premium so that sick people don't have to pay for their own healthcare caused premiums for the healthy middle class to rise.

More people are getting healthcare, hence more money is needed, and instead of raising taxes to pay for taxpayer funded healthcare, the US government decided to force health insurances to cover people who had to raise health "insurance" premiums.

More people were never going to get healthcare without an increase in either taxes or insurance premiums. Complaining about higher premiums is therefore complaining about more people getting healthcare, unless you would have rather higher taxes on the wealthy to pay for taxpayer funded healthcare for everyone.</comment></comment></comment></comment>


The Ace of Coders programming tournament champions - <AUTHOR> http://blog.codecombat.com/the-true-ace-of-coders <comment><USER2> Thank you for this. I didn't quite make it into the top 10, but it was a lot of fun. I really like what you guys are doing. I began learning to code by writing bots for games so your approach to teaching is a lot of fun. It looks like lots of others enjoy learning to code this way too.

I'm very curious about and hope that you'll post your opinion on the success of this tournament as a channel for hiring. This is a refreshing approach to filtering candidates that, hopefully, will be adopted by many others. I'm also curious to know if the tournament accelerated new user sign-ups. Perhaps the extra incentive (an interview was offered to the top 10 players) was enough to convince some to learn to code who would've put it off otherwise.

Thank you again. I hope the result of this tournament will be very positive for CodeCombat, and I wish you all the best moving forward.

</comment><comment><USER3> That looks like so much fun :)

[update]

Hmm, just played 15 levels to find out I have to play $9.99/mo to continue :-/ Would be good to know that up front...

<comment><AUTHOR> Just keep clicking the red levels–those are the free ones. The blue ones are the subscriber bonus levels.

</comment></comment><comment><USER4> I remember doing RoboCode in Java back in the day. Was fun to participate, though back then the best I could do was a bot that always ran middle of the pack in any tournament.

</comment><comment><USER5> I think you guys are awesome. Loved watching the videos. Just a suggestion, You guys might want to visit this site of live coding [https://www.livecoding.tv/livestreams/](https://www.livecoding.tv/livestreams/). Also a great way to interact with fellow coders.

</comment><comment><USER6> Is it possible to get videos of the battles?

<comment><USER7> On [http://codecombat.com/play/ladder/ace-of- coders#winners](http://codecombat.com/play/ladder/ace-of-coders#winners), there's a column of links which say "Watch the battle."

</comment></comment><comment><USER8> Are there instructions? I tried to do the warmup... I have no idea what is happening or what I'm supposed to do.</comment>


Audrey – A smart personal assistant app that helps you to get things done - <AUTHOR> https://getaudrey.com <comment><USER2> On a slightly related note, I, personally, noticed that I don't want to get things done. Most of the things, at least. After working GTD style I feel happier and more productive, but usually not closer to my goals. I found, that failing do to most of the things is bearable, as long as I'm keep doing things that matter.

I'm still using GTD stuff, but just to "better forget", to unload working memory.

<comment><USER3> > _I don 't want to get things done_

Exactly. This is a really, really difficult and essential observation to make. Humans are built to procrastinate because it conserves energy.

Do an experiment: Sit down and start doing what you are supposed to do. If you're not able to work or start, don't find excuses. Don't go looking for physical reasons like "Hungry", "Cold", "Tired". Don't procrastinate. Don't walk around. Don't work around the issue. Don't change the project. Those are all excuses. Just accept that you are not able to start and keep sitting there until you start.

When you stop finding excuses or looking elsewhere, you will realise the immense stress that's building up inside you. That is the mountain you have to scale to stop procrastinating. A kind of stress that's not always there, luckily, but it's definitely built into humans.

<comment><USER4> I find that the problem is often the context switching.

To get things done, I often have to take a step back and make a list of things that need to get done. This is the top-down brainstorming, that gets me more in the mood. I can do this when I'm not working, to get me thinking about the problem.

Then when the time comes for working, you choose the easiest or shortest task and start on it. The "McDonalds theory" as stated on phpjs is that you can do a shitty job on your first iteration as long as you get it done. When you did it, or usually even as you are working, you have the urge to improve it. And that's where the excitement and emotional investment comes.

Russians have an expression for this: _Appetite comes when you start eating._

<comment><USER3> Yes, I do that as well. Start somewhere and work yourself into the mood. I keep the larger issue in mind though, to not spend too much time on improving "alibi"-subprojects.

Regarding the "McDonalds theory": I call that "Don't mix production and criticism of your work." Either produce something or improve on you've already done. Otherwise these two modes of operation interfere with each other.

</comment></comment></comment></comment><comment><USER5> I hope this is helpful feedback:

* There are several small typos on the page ("How does it works?") that distract from its content.

* The testimonials strike me as all having the same writer's voice.

* What appears to set "Audrey" aside from, say, Alexa is the promise that you can take a moment to train the AI when it misunderstands you. That's a great feature; I can tell Alexa that she was wrong (via the app), but that's tedious and may take months to see my feedback enacted. Immediately linking what I said to the desired outcome for future use would be ideal. I'd like to see an example of what that looks like for this app, even if it's just a mock-up.

<comment><USER6> _The testimonials strike me as all having the same writer 's voice._

Someone needs to come up with a service that generates authentic-sounding testimonials, complete with convincing headshots.

<comment><USER7> At the very least, one of them is obviously a headshot found from somewhere else. In general for a new service, I'd rather see no testimonials than testimonials of questionable authenticity.

<comment><USER8> Agree. They should have known their technical audience would pick up on this.

</comment></comment></comment></comment><comment><USER9> Nothing against this application personally, but I still do not understand the appeal of "personal assistants." If I want the weather, I click my weather app icon and see it instantly. If I want an Uber, I click Uber and request one instantly.

I don't see the benefit of adding another layer between me and my desired action. This is especially the case when the smart personal assistant doesn't understand my request, in which case I'll usually just abandon the whole thing. Only took a few times trying to get Siri to do something and I haven't used it for anything besides timers in years.

<comment><USER10> For simple tasks like that, maybe I would agree. But as tasks get increasingly more complex, they take longer to do manually and the assistant ends up significantly reducing the work to do the action.

For example, "play Skrillex on Spotify" Manually I would have to find Spotify, go to the search, type in Skrillex, etc.

</comment></comment><comment><USER11> I love the design for this. Excellent!

As a side note, I'm curious to how/why you named it Audrey. I think it's very interesting that these 'personal assistants' have traditionally feminine names.

P.S. At the bottom, "Here's are some" is not grammatically correct.

<comment><USER12> I've heard more than a few women complain that all the bots in the "service" area tend to get female names.

<comment><USER13> At least one blogger preferred Googles assistant because she was ordering around an impersonal un-gendered corporation rather than what felt like an individual.

That said, this does seem like a great opportunity for Ask to bring Jeeves back.

</comment></comment></comment><comment><USER14> > How Does It Works?

For a natural language processor, they sure could benefit from better proofreading.

</comment><comment><USER15> For a moment I thought the original Audrey assistant was reborn: [https://en.wikipedia.org/wiki/3Com_Audrey](https://en.wikipedia.org/wiki/3Com_Audrey)

<comment><AUTHOR> We had been told that a several time and we immediately check if we infringed anything. Turns out, we are clear :) Good ol times.

<comment><USER15> I was at 3Com at that time. Awesome product, bad timing.

Good luck with yours!

</comment></comment></comment><comment><USER16> I don't typically use assistants and voice based interfaces beyond "Alexa, what's the weather" which is arguably not that impressive.

However... I welcome 3rd party, independent applications of this type, because I find it dull that all the existing solutions from big companies are just trying to upsell their own services by forcing you to have an account with them, listen to their music or shop from their shop... Some independent thinking is due in this space.

</comment><comment><USER17> Mhm.

So yet another Siri.

Apparently "Vernax" is behind it: [https://www.crunchbase.com/organization/vernax#/entity](https://www.crunchbase.com/organization/vernax#/entity)

Website is down: [http://www.vernax.com/](http://www.vernax.com/)

They really need a native English speaker to clean up the text on the homepage though. Lot's of sub-optimal phrasing.

<comment><USER18> They're from Toronto! That makes it even weirder that they have some pretty rough ESL issues.

<comment><AUTHOR> We're non native speaker. We didn't update our Crunchbase for a long long time and now we are in Japan now. Sorry.

</comment></comment></comment><comment><USER19> This looks interesting, but I really need to see their Privacy Policy first.

<comment><AUTHOR> Hi, we're sorry about it. We will update the site as soon as possible with the privacy policy. Thank you for your patient.

</comment></comment><comment><USER20> I wonder how it is different from Magic

[https://getmagic.com/](https://getmagic.com/)

[https://news.ycombinator.com/item?id=9087819](https://news.ycombinator.com/item?id=9087819)

</comment><comment><USER21> Design looks like Instagram Stories at the top + IFTTT for the cards. Could be interesting but definitely not sharing it to go up the list or whatever, I always felt like that approach was no good for products nobody has ever tried.

</comment><comment><USER22> > It reinvents how people interact with artificial intelligence by allowing > you to teach it instead of guessing what it'll understand.

Putting out an app like this seems like a great idea, if only to have a platform to start collecting and cleaning data (for your MTurkers, relatives, and bored employees). Speaking of which the privacy policy link goes nowhere...

On a related note, does anyone have details on the penalties for not having a privacy policy on a Google Play app? They seem to be a little more insistent on having one than Apple.

</comment><comment><USER23> Their privacy policy is concerning.

</comment><comment><USER24> "Request accesss". How do I know you're just not running some sort of marketing study/proof of demand?

<comment><AUTHOR> We don't play a fool.

[https://www.youtube.com/watch?v=GDlAqhulJmw&t=1s](https://www.youtube.com/watch?v=GDlAqhulJmw&t=1s)

<comment><USER25> Thank you for the video!

My 5 cents: Please make the small x (close button) to something else, like swipe to up to close the dialog. Small x is not good gui for mobile phone apps.

<comment><AUTHOR> Thank you for the feedback. We'll definitely surprise you!

</comment></comment></comment></comment><comment><USER26> "Whenever Audrey do not understand the request, you are able to train it directly in just a few taps."-typo

</comment><comment><USER27> Although I welcome them, the problem with all these AI products is the there's little promise of zero-knowledge (or whatever you wanna call it) privacy/security. Until then, I don't see myself feeding a company my information, at least not for free.

</comment><comment><USER28> > Small Talk > Whenever you want to burn some time, you can have a simple > conversation with Audrey.

What is wrong with talking to real people ? It is a sad world where this is perceived as a beneficial feature.

</comment><comment><AUTHOR> I noticed that we made a mistake not having it proofread. We're dragging someone here to proofread and make those correction. But in the same time, I'm thankful that the community here is correcting it! It's Audrey in real life!

<comment><USER29> "every day" is 2 words in your case.

</comment></comment><comment> d--b Someone should tell them that using actual names for a digital assistant is a terrible idea. At least they should use a name that's not so common. And easier to pronounce!

</comment><comment><USER30> I like the approach where you see all the connections app has, it gives you a context about what can be done with it. You don't feel lost like most virtual personal assistants.

</comment><comment><USER10> I'm not sure if this was intentional, but the name Eliza in the demo text reminded me of the hours I spent playing with the ELIZA bot as a kid.

<comment><AUTHOR> It is ;)

</comment></comment><comment><USER31> Why does every assistant has to have a woman's name?

Is it really that hard to come up with a name?

<comment><USER32> Bixby, Siri, Cortana and "OK Google" are women's names? The only one with a woman's name that I can think of is Alexa. Granted they all have a woman's voice, but doesnt seem like that was your point.

<comment><USER33> Siri is absolutely a fairly common Nordic woman's name, I know several people with that name.

<comment><USER34> And Cortana was named after a female video game character.

</comment></comment></comment></comment><comment><USER35> Is this another cloud based assistant or one I can install and run locally?

</comment><comment><USER36> My girlfriend won't appreciate another invisible girl I talk to at home.

<comment><USER37> HN has never really struck me as a great place to solicit relationship advice. Not really the focus of the community.

<comment><USER36> I am profoundly saddened to hear you don't get jokes. Funny guy.

<comment><USER37> Oh, I get it. I just don't want it. Because it's not funny. That's why I made fun of it. If you'd made a good joke, I'd be laughing with you. But you made a bad one, so I'm laughing at you. I didn't put a lot of effort into doing it, though. Next time I'll do more to make it clear.</comment></comment></comment></comment>


How to teach Git - <AUTHOR> https://rachelcarmena.github.io/2018/12/12/how-to-teach-git.html <comment><USER2> And here is something to take the garbage quality of Git manpages with some humor

[https://git-man-page-generator.lokaltog.net/](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. [...]"

<comment><USER3> 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's not very good at UI stuff (I mean command line as well)... it's truly a sad thing.

This is a major 'problem that needs to be solved' I'm interested to see how it could evolve into something 'better'.

<comment><USER4> 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.

<comment><USER5> 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.

<comment><USER3> 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.

<comment><USER6> 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.

</comment></comment></comment></comment></comment></comment><comment><USER7> 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 when two changes conflict, and how to resolve merge conflicts. Using git on the command line only.

Then, have the students use git for a big-ish multi-student project. They will figure out the workflow themselves. After that project, once they understand the basics, you can talk about branches, debasing, the log and reflog, pull requests, and all the rest. Don't introduce graphical front ends before this point.

This method works well. It takes about one hour of teaching, and five weeks of active use afterwards. Git is a total pain to learn, and can only be understood by actively using it. I often get very positive feedback for having taught git.

I have gone through a few iterations with this topic, and have found that stripping down the initial instructions to an absolute minimum works best. All those fancy box diagrams are actively harmful to beginners.

<comment><USER8> 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.

<comment><USER9> Does anyone really feel comfortable with git? I've been using it for over a decade, in a handful of different organizations, on projects large and small, both at work and for personal projects, and it still feels like a convoluted mess. Its terminology is wildly inconsistent and my mental model of its behavior remains stubbornly full of fog. I have a library of recipes committed to memory, but I still don't really _understand_ it, and sorting out what's gone wrong when things inevitably go wrong remains challenging.

</comment></comment></comment><comment><USER10> 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".

<comment><USER11> `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.

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

<comment><USER13> This makes a lot more sense when you realise that Linus thought he was building a low level tool that people _would_ build a UI on top of. The 'original' git command line was more a proof of concept and engineering tool than something aimed at actual use.

<comment><USER14> Right, doing a search through the git mailing list for the use of the word "porcelain" is fascinating. It's unfortunate some of those "porcelain" projects never finished.

<comment><USER15> ... because none of the power users used them.

<comment> yjftsjthsd-h Heh. I think Linux on desktop it is like that, at least a bit; frequently, by the time someone could write a friendly GUI (or friendly CLI for that matter), they have little use for it.

<comment><USER16> That's a disturbingly insightful parable for everything from startups to linux/FOSS contributions.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> An honest criticism:

If I had trouble with understanding the reason behind add->commit->push workflow, I would definitely have no idea what this article talks about when it says things like "merge, rebase, diamond shape". The flow chart looks almost exactly the same for "pull" and "pull --rebase". The only difference between the charts is the wording which has no meaning at all for a newbie.

<comment><USER18> It sounds stupid but something that really simplified git to me as an absolute beginner about a year ago was the fact that it doesn't exist on GitHub. Knowing that git was just something that sat in the folder on your filesystem and monitored changes took away the notion that there is some kind of sync between your remote and local. Working just on my own laptop made me realise how intuitive all the commands and strategies for solving problems were. Then came pushing, pulling etc between branches and it all just fell into place.

<comment><USER19> I wouldn't say it monitors the directory, because there is no git daemon running. Git just looks at the changes whenever you run a git command

</comment></comment></comment><comment><USER20> 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....)

<comment><USER21> My recommendations:

* Git From the Bottom Up: [https://jwiegley.github.io/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](http://ftp.newartisans.com/pub/git.from.bottom.up.pdf)) (See also: "Linus Torvalds' greatest invention": [http://perl.plover.com/yak/git/](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](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).

<comment><USER22> Thanks! Awesome resources! I'll add it to my post as soon as I finish reading all the answers. I'm learning a lot from you!

</comment></comment></comment><comment><USER23> Humbly, I'd disagree that's the best, though this is a superb _part_ of the picture to teach Git well. These are nearly the last steps, I would say.

When new colleagues joined our firm and hadn't yet learned Git, the problems were always the same: uncertainty. They didn't know which Git operations were safe, and they didn't understand how to perform seemingly risky maneuvers with zero risk. They're used to even more dangerous tools that can wipe your work in a second - and, to be fair, Git can as well. The difference is that once you understand Git, you never have to worry about losing work.

So the way I would teach Git is to honestly start with the graph. Show it in action with pictures. Show how to always keep references to commits around to ensure work sticks around. Show how branching and stashing work, let them be confident that the tool will keep everything right where you left it.

_Then_, once they're confident in the basics, weave in the remote repositories.

<comment><USER24> > So the way I would teach Git is to honestly start with the graph. Show it in > action with pictures. Show how to always keep references to commits around > to ensure work sticks around. Show how branching and stashing work, let them > be confident that the tool will keep everything right where you left it.

Personally, I think this should be coupled with teaching `git reflog` as the universal undo (as long as they don't `gc`).

<comment><USER25> Don't teach anybody git gc. The people who really need to find it will come upon it all on their own.

</comment></comment></comment><comment><USER26> 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".

<comment><USER27> > WHY there is a staging area

I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging?

You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?

<comment><USER28> 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, it would be a blind commit with no guarantee that things are working.

Very rare is the situation that I can break out a list of files over here that are for feature A and some over there for feature B, and never the two shall interact.

I think this is probably what most struggle with regarding the staging area, without being able to articulate it.

<comment><USER29> You never amend commits or rebase locally before pushing? I rebase before pushing almost every time.

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.

<comment><USER30> > 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".

<comment><USER29> 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. Without a staging area, you'd either have to always fix mistakes with new commits, which is bad, or rewrite already pushed history, which is worse.

<comment><USER30> > 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".

<comment><USER29> > 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.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Git itself is so simple, it's all the stuff around it that can be overwhelming. Social mores about all the possible workflows are maybe the biggest (rebasing vs merging, granularity of branches and their longevity, acceptance of partial commits reflecting a state never realized in isolation on disk, commit hooks, requirement of every commit to satisfy properties x,y,z, direct access to common parent repo copy vs requiring some sort of pull request flow (and dependence on github and all their stuff)) but there's also work tracking, code review, build automation, test automation, deploy automation...

</comment><comment><USER32> 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 almost dig itself out of that hole, but it took over a decade. Gimp is still down in the pit.

<comment><USER33> 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 this bug. Plus it likes to crash right after shutting down the VM. I'm not really sure if there's some deeper philosophical reason behind this dichotomy, but I've seen it hold true for a lot of apps and their open source alternatives, and many people have said the same thing holds true about my app Autumn and open source alternatives like Hammerspoon and Mjolnir. As a rule, we really do seem to get what we pay for.

<comment><USER34> 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 Qemu/KVM. Which obviously doesn't support any apple OS either, because they're not allowed to virtualize it. Take that up with Apple, not open source

<comment><USER33> 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.

<comment><USER35> > Paid products generally tend to be higher quality than open source, for > whatever reason.

Putting aside the fact that this isn't true, and that there are quite a few quality open source apps on macOS, it's pretty clear why paid products have higher quality: the bar for people to buy them is much higher, so they generally need to be at least somewhat decent for people to consider paying for them.

</comment></comment></comment></comment></comment><comment><USER36> No one is appreciating the effort and a different take here. Let me congratulate the author on job well done.

There are people who love illustrated explanation and for those these are perfect. This is just meant as a template which others can use to build the illustrated material and in no way a comprehensive git tutorial.

<comment><USER37> I completely agree. I've seen a lot of these, and this one is simple, to the point and easy to understand.

</comment></comment><comment><USER38> I gave a git talk at work recently and what I found works was teach the graph from the beginning. This includes a lot of diagrams of what the graph looks like as you commit and branch:

\- show what happens as you add commits to a branch \- show that branches are just pointers to commits \- show what creating new branches looks like, i.e. creating a new pointer \- show what merging looks like (a new merge commit is added, or else fast-forward merge and that the branch pointer just moves) \- show what happens if you don't rebase (i.e. "ugly" non-linear graph) ... then teach what rebasing does (i.e. creates new nodes and moves the pointer)

I found that building up from the ground up and illustrating graphs allowed people to conceptualize things much better. There was still some confusion once merging was introduced (what happens to those earlier commits? do we need them?) and mostly because people hadn't thought of the graph before.

Git is one of those tools where you can totally do your job just by knowing the basic commands but not really know what is happening under the surface, which I think is a testament to the tool. But, that leads people to conceptualize their own idea of what is going on... and getting it wrong and being confused when they want to do something outside of their basic toolset.

<comment><USER39> Yeah, it was definitely a set of images [0] that made git click for me, but even those are not necessarily the best pictures to use.

Git's mental model is basically:

> Ok, what if we took our SVN repository and the first thing we did was check > in an SVN repository to that. So now you check out the repository, and you > get a complete local repository that you can do anything you want with!

> So Pull/Push are the terms we use for the check out and commit of your local > repository to the remote repository, and then Checkout/Commit works from > your local repository just like you're used to with SVN.

And the real magic is what they did by building a system on top of this model to let you merge changes all the way up while looking at the code like you'd expect you'd need to.

The problem is that git's toolchain still feels arcane to use, and it _requires_ that you have good working knowledge of the underlying models. It's confusing enough that you can't function unless you have that because you don't know where you are or where you're going. It's a fantastic tool, but it's like driving a car with two steering wheels, two gear shifters, and six pedals. Then you say to yourself, "How do I get to the market, buy some milk, and come right home?" and your brain starts to melt a little bit.

You shouldn't _need_ to know the nitty gritty of how git works internally just to get it to work right any more than you should need to know how a disk works in order use a file system, but over and over we keep seeing that knowing that is really the only way to use the tool correctly and that it takes quite awhile for people to get.

[0]: [https://blog.osteele.com/2008/05/my-git- workflow/](https://blog.osteele.com/2008/05/my-git-workflow/)

</comment></comment><comment><USER40> When I was first learning git, I found an online visualizer like this [0] that really helped make make concrete the ideas of git history being a graph, and what different operations did on that graph.

There was still obviously the issue of memorizing the commands, but at least I knew what the commands were doing on a deeper level.

[0] [https://learngitbranching.js.org/](https://learngitbranching.js.org/)

<comment><USER41> The other problem I find in git is that there are many GUI interfaces and none of them are consistent. In Eclipse I had a different interface depending on what project I opened, despite both the projects being in Python.

</comment></comment><comment><USER42> I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive.

[https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2)

<comment><USER43> Great idea. This kind of culture is why there are a lot of people that don't and probably never will use git.

<comment><USER44> The article is about how to get a more fundamental understanding idea on how git works, and this book demonstrates fundamental ideas on how git works. I don't see a problem in this reccomendation. If you want just a cursory knowledge of how to use git to get by, this probably not the right choice, but that's not really what this discussion is about is it?

<comment><USER15> Well, that is what the article is about.

</comment></comment></comment></comment><comment><USER45> I like the diagrams, as many explanations often skip the staging portion of the whole git process. I use that so much that it baffles me that most people skip it. Then again, I typically don't like having tons of "WIP" commits so I stage a lot and if I need to switch to another branch I'll commit a WIP that I quickly `rebase -i` to get back to a clean status.

As for the teaching part, I have found the best results by having you and the learner actually "working" on the project at the same time on your own machines both pushing to a centralized server. It becomes too easy to go over all the commands and feel like you understand it. Most of the scary parts of git are used when its multiple developers on the same project. And oddly enough, having the learner do both Developer A and Developer B's tasks don't seem to work as well as having the learner just do Developer B while I do Developer A. Trying to explain to someone when to use merge, when to rebase, and when to use cherry-picking to get the code I just pushed into their current working branch can be done so much easier when its hands on AND knowing exactly who is doing what steps.

</comment><comment><USER46> I found this very helpful: [http://eagain.net/articles/git-for-computer- scientists/](http://eagain.net/articles/git-for-computer-scientists/). Git's data structures are well designed. Once you have internalized them, you will be better equipped to navigate through the jungle of command-line options.

To understand the data structures interactively, use "git cat-file -p HEAD" and continue drilling down to an individual file in a subdirectory with "git cat-file -p _OBJECTHASH_ "

<comment><USER47> 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?

<comment><USER48> 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.

<comment><USER12> 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.

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

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

<comment><USER49> 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.

<comment><USER12> 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").

<comment><USER49> 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)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER50> As unorthodox as it is, the way I learned Git was through re-implementing it as a project for the data structures course I was taking [1]. This isn't the method I would entirely recommend to most people: instead, like the author, make a diagram for each of the (most-used/basic) commands and sketch out how they interact with the data structures. [2] is a good starting point.

[1] [https://inst.eecs.berkeley.edu/~cs61b/fa17/materials/proj/pr...](https://inst.eecs.berkeley.edu/~cs61b/fa17/materials/proj/proj3/index.html)

[2] [https://git-scm.com/](https://git-scm.com/)

</comment><comment><USER51> I got mixed results with a completely different approach: starting with what actually exists within a Git repository (i.e. roughly: focusing on aspects of the plumbing layer first).

However, this only works with people who can make the mental leap to be able to deduce knowledge of what should be from knowledge about what is. In the end, I concluded it's a bit like teaching cooking. There are those folks who need to be taught about full recipes and those who need to be taught about resources and corresponding steps.

I have not yet seen a working approach to make both of these fractions happy, unfortunately.

</comment><comment><USER52> This is a pretty great overview! However, I learned Git and Github from Udacity's free course [1] and it was amazing to me since I am more of a visual learner. It got me up and running with Git within a week or two. I recommend others who have no prior experience with Git to check it out.

[1] [https://www.udacity.com/course/how-to-use-git-and-github-- ud...](https://www.udacity.com/course/how-to-use-git-and-github--ud775#)

</comment><comment><USER53> I once taught[1] the building blocks of git (basically bullet time view of a commit) and people found it a bit too theoretical - even though it contained all the elements, that helped me to understand and appreciate the simplicity.

There is a point, where you go from memorization (add, push, commit) to deduction (graph, objects and refs) but when this point is reached, depends on many individual factors.

[1] [https://git.io/fhWxg](https://git.io/fhWxg)

</comment><comment><USER54> Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies.

Using a git GUI works quite well for people inexperienced with git.

<comment><USER55> Its opposite for me. I am very comfortable with the command line. It lets me do crazy things and if I mess up, quitely crawl back to the peaceful place.

GUI integrations have some advantages but the knowledge is not transferrable. Different GUIs work differently but the commands stay the same. I think both can complement each other. I use Pycharm a lot and it is a lot easier to see diffs or file history there. I think the same can be done with cmd as well but I don't think I ever bothered to learn advanced commands.

<comment><USER56> Committing to version control is one of the ideal uses of a GUI. You can skim your eye over the files you've changed, and flick between their diffs by just clicking on their file names, before going ahead with the commit. You can simultaneously cast your eye over recent commits in the revision history. Of course these are easily accesible with git status and git log (|less) but it's not the same as dealing with the information graphically.

I would posit the ed text editor for comparison. Why bother with a graphical text editor (including terminal editors like Vi and Emacs)? After all, you can look at the context surrounding lines you wish to edit by entering the appropriate ed commands.

I think it comes down to developers being so used to working with command line tools that they don't give GUIs a proper chance - ironically the exact objection they have with less experienced users not using the command line.

</comment></comment></comment><comment><USER57> I think the best thing you could do for novices is to avoid priming them with preconceptions of Git being difficult. Psyching people up before instructing them never seems to do people any good, yet it's very common.

<comment><USER58> I agree with this. For many people who are learning Git for the first time, it's also their first experience with contributing code to a repository at all.

The last thing you want to do is turn them off entirely, or gatekeep the profession to exclude people who aren't good at reading dense documentation.

The best way to teach git is to get them comfortable with "Add, Commit, and Push" and _then_ explain what's happening at each stage.

<comment><USER57> Despite using CVS and SVN for years, I was never truly comfortable with either. When I first learned git, it was like a breath of fresh air. Suddenly the VCS was behaving in predictable ways. Yet I'd put off learning git for two or three years because everybody was telling me _" git is so much more confusing than subversion."_ I shouldn't have listened to them, and they shouldn't have said that!

Maybe if somebody has already _mastered_ subversion then git will confuse them a lot, but I'm not convinced even that is necessarily true. Regardless, it seems clear to me that novice users shouldn't be told that git is complicated.

</comment></comment></comment><comment><USER59> This is missing pointing everyone at a phenomenal ncurses git log viewer: [https://github.com/jonas/tig](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.

<comment><USER60> 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...](https://www.flickr.com/photos/jonasfonseca/sets/72157614470764617)

<comment><USER59> 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](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](https://i.imgur.com/yd7cSd1.jpg)

</comment></comment></comment><comment><USER61> Years ago, I tried to teach git to my (college) students, and it was a complete disaster. Like a lot of technical things, it's easy to get them totally confused with a single off-the-cuff sentence (and to be honest, I think I underestimated how difficult it would be to explain it and the kinds of pain points they'd encounter).

Reading this article, it occurs to me how useful the idea of a "staging area" would be to helping them understand. I don't think of it that way myself when I'm working with it (I suppose I do, but not in those precise terms). But looking back, that's what was tripping them up. If you're just talking about local and remote repositories, you're not really giving them the right idea of the workflow.

</comment><comment><USER62> I found teaching Git to someone unfamiliar with any other VCS was far easier than teaching someone who already knew SVN.

</comment><comment><USER63> I only have a sample of 1 (my wife) but I've found Ungit: [https://github.com/FredrikNoren/ungit](https://github.com/FredrikNoren/ungit) unparalleled for explaining the graph model behind git — what's a merge, what it means to fetch vs pull, what's the difference between committing locally vs push etc...

The specific points that make it great for such teaching:

1\. pretty graph

2\. hovering over actions such as Commit / Merge / Rebase / Push shows what _would_ happen to the graph if you do it.

3\. you can manually "Move" local & remote branches anywhere you want! This is mildly risky as a habit, but much clearer to explain than fast-forward and push, especially with multiple remotes.

4\. automatic fetch that works pretty well (though explicit fetch UI with multiple remotes is clunky). For people scared of merging and conflicts, it's liberating to teach "fetch is always safe" and "local commit is always safe", and that you can fast-forward or merge/rebase separate step.

</comment><comment><USER64> 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.

</comment><comment><USER65> Shameless plug: "GIT isn't perfect, and other blasphemies."

[https://blog.hackensplat.com/2018/12/git-isnt-perfect-and- ot...](https://blog.hackensplat.com/2018/12/git-isnt-perfect-and-other- blasphemies.html)

(Addresses some of the points raised in this article.)

</comment><comment><USER66> I like the painting analogy and have used it frequently.

Let's say you were commissioned to create a landscape painting. It'll be a big payday if you get it right and its due in 30 days.

Because you know you can make mistakes, you make a photo copy of your work every day and make a stack of them neatly on your desk. This photo copier is really high quality as copies are made at the molecular level.

On day 16, you find yourself working on the mountains in the picture. You sneeze and Oh no! You got paint all over your work. But since you have your copy pile, you just make another copy of day 15 and keep going.

But lets say you think its a lot and want a friend to work on the painting too. Just allow her to copy your latest photocopy and you both are off to the races!

Git seems complex but when you bring it down to a practical, non technical level, beginners pick it up faster :)

</comment><comment><USER67> Some ideas on how to teach it non-verbally in class, regarding the add, commit, push workflow:

In class I'd stand on my right side, so students see me on the left (people are more used to left to right motions because of reading).

I'd demarcate the working directory, staging area and local repository non- verbally as 3 different spaces. My most right space (the student's left) was the working directory, my most right space (the student's right) was the local repository.

Everytime I'd make a transition from one space to another through add or commit, I'd make a hand gesture when I'd say "add" or "commit".

In order to add some humor (humor is rememerability) with push I'd point upwards to the ceiling as if I were looking to God. I'm not religious, but people got the reference and they all left out loud.

</comment><comment><USER68> Many developers view git (and other "helper" tools like text editors, linters, grep, SQL, ... everything but their programming language) as second-class citizens.

The way to teach these tools is to make them primary citizens in your company culture. Emphasize that, without a strong grasp on a variety of important tools, devs will be unable to perform at or above the bar. Don't promote anyone to "senior" engineer who can't easily show the benefits of these tools while a junior engineer pairs with them.

Otherwise, developers will teach themselves the absolute bare minimum necessary to get their jobs done and go home. The quality of the training materials is of minimal importance. I learned git because I wanted to be better at it.

</comment><comment><USER69> I applaud this effort, but it's still not hitting the right notes, eg:

> how to show the changes of a file in the staging area: git diff --staged

Ok, but this shows the diff against what: the file in the working directory, the file in the local repo, or the file in the remote repo?

<comment><USER70> Agreed that this is lacking. Staged is what will be included in the next commit (as made by git commit). So it is a diff against HEAD (current commit).

Also, it does not show a particular file, but all the changes in the staging area. To show only one file have to do `git diff --staged -- src/myfile.c`

</comment></comment><comment><USER71> I agree with the author - many developers learn git (or version control in general) along the way, even though it's a fundamental skill needed for almost every project out there. This leads to insecurities, inefficencies and wasted time when (not if) something breaks. That's why our company training for new graduate hires consists - among others - of 2 days of git/github training. I love git (even though I might experience some sort of Stockholm syndrome), and while it's the most popular VCS, it is not an easy tool to learn and should not be condensed into "commit - pull - push - now start working on some tickets".

</comment><comment><USER72> 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 needed more in a number of companies.

[Yes, somewhat tongue-in-cheek and of course limited to people who use Windows and Visual Studio, but I have discovered that's a significant number.]

<comment><USER73> Yeah that's probably a good bare minimum amount of git knowledge. But I feel like that's making git which can be a super helpful and powerful tool nothing more than a means to an end.

Learning the functionality of git can really help you out. For example, I almost always use the `-p` flag (particularly `git add -p` which gives me a chance to manually see every change I've made, often I'll find some junk that I may have left somewhere else. Also being familiar with how to rebase series of commits onto and off of other branches can be a huge time saver.

<comment><USER74> > But I feel like that's making git which can be a super helpful and powerful > tool nothing more than a means to an end.

It also feels like a clunkier workflow than just using git from the command line. It's probably easier to get started that way, but learning the basics of git from the command line isn't too hard.

</comment></comment></comment><comment><USER75> Just yesterday I attempted to explain to my colleagues (who have been mainframe developers all their life) the concept of having multiple remote repositories and different possible setups. I think I explained adding remote repositories well enough, and mentioned the use cases for such a setup -- having only read access from a repository and needing to develop in a fork while keeping up to date with the original.

Does anyone have a good analogy for this? I think they understood for the most part, but explaining things better is something I have been really trying to improve on in the workplace lately.

<comment><USER44> I really think showing them how it works visually with a DAG is a great way to show someone how git works. Also, Linus has a great talk about git and how it works here: [https://m.youtube.com/watch?v=4XpnKHJAok8](https://m.youtube.com/watch?v=4XpnKHJAok8)

(Sorry for mobile link, I'm on my phone RN)

</comment></comment><comment><USER76> I feel that Atlassian's git tutorial is the best I have come across so far.

[https://www.atlassian.com/git/tutorials](https://www.atlassian.com/git/tutorials)

</comment><comment><USER77> I've had to teach git to several people. Here is what i teach:

\- never force push (with exceptions) \- don't use reset (with exceptions) \- don't commit to master \- stop immediately if git tells you, you have 200 changes

Aside from that, people don't really seem to have trouble. Git is pretty functional with just add, commit, push, pull. People learn more commands as they need them.

This post was humor

<comment><USER78> Hahah, once at work a guy force pushed to a branch that was just about to be merged. This almost resulted in some guys work being lost but luckily it was recovered.

This was immediately followed by another dev writing 'DO NOT FORCE PUSH' on a post-it and sticking it to his monitor :D

Edit: I meant merged not committed.

</comment></comment><comment><USER79> I really like these two resources for learning git

[http://ndpsoftware.com/git- cheatsheet.html#loc=workspace;](http://ndpsoftware.com/git- cheatsheet.html#loc=workspace;)

Guided tour - [http://gitimmersion.com/](http://gitimmersion.com/)

</comment><comment><USER80> For anyone looking for resources on teaching git I'd recommend the software carpentries - all open source with a great community behind it. [http://swcarpentry.github.io/git-novice/](http://swcarpentry.github.io/git- novice/)

</comment><comment><USER81> 'How to teach Git' was something I had to think a lot about when a lot of my technical colleagues didn't know what a rebase was, and asked me to sort out their 12-team merge history (the 'git log --graph --oneline' spanned the width of multiple pages before you could see any commit message at all).

I realised that there's a point you can't progress beyond with git without having to do some thinking and learning. And lots of people aren't interested in the theory behind distributed file content. So I took Zed Shaw's hard way method and applied it to git. It made for a really enjoyable course at work and I then turned it into a book (1).

The tl;dr is I believe you need real world experience with a mentor prodding you at the appropriate time to think a bit deeper. Then the understanding will follow.

Here's an example from an 'advanced' chapter: [https://zwischenzugs.com/2019/01/09/git-hooks-the-hard- way/](https://zwischenzugs.com/2019/01/09/git-hooks-the-hard-way/)

[1] [https://leanpub.com/learngitthehardway](https://leanpub.com/learngitthehardway)

</comment><comment><USER82> 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.

</comment><comment><USER83> I contribute to git, if anyone's got any UI warts they're bothered by in particular I'd love to hear about them. Maybe it's something we can fix.

<comment><USER84> LFS works by installing hooks. This prevents me from adding my own. Also the one-hook-only policy makes it harder to share hooks.

<comment><USER83> Yeah this would be great. I started working on adding support for <hook>.d/* in addition to <hook> a couple of years ago, that got to a proof-of-concept stage, but some of the long tail is hard to handle so I dropped it, but it could be finished.

There was also a disagreement about what the semantics should be, e.g pre- receive.d/* hooks failing on the first one that failed in glob() order or not, which has implications for whether they can run in parallel.

The bit that stuck from those patches was being able to configure the the core.hooksPath variable to a hook path, which _sometimes_ can with some stretching fulfill some of the use-cases, but most users end up with a meta- hook runner of some sort.

<comment><USER84> Glob() is (iirc) not sorted in any way on macos. I would prefer alphanumerical sort by name as it is stable across OSs.

Parallelization is optimization so I think «make it right, then make it fast» is sound advice.

<comment><USER83> The glob() function is sorted consistently on all platforms. It's mandated by POSIX[1], and from the OSX docs I could find[2] sorted unless you specify the POSIX GLOB_NOSORT flag, as on other platforms.

In any case, even if glob() wasn't portable it's easy to provide an API compatibility layer that's just readdir() + qsort(). That part would be trivial, and might perhaps be needed due to collation issues in the sort.

Doing it in parallel (preferably in a random order) isn't just an optimization, but would ensure that there isn't an implicit dependency on whatever iterative interface we'd first ship with.

1\. [http://pubs.opengroup.org/onlinepubs/009695299/functions/glo...](http://pubs.opengroup.org/onlinepubs/009695299/functions/glob.html)

2\. [https://developer.apple.com/library/archive/documentation/Sy...](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/glob.3.html)

</comment></comment></comment></comment></comment><comment> black-tea The best way to learn git is to learn what's happening at the DAG level. That way you can think about what should happen on the DAG and then think of how you can use git to achieve that. For example, a fast-forward merge and a reset can be used to achieve the same thing.

It's also very important to learn to use the reflog. When I was learning to climb they told me I'd never get really good until I'd fallen once. The same thing goes for git. People are really scared of it because they think they could lose work or something. Thanks to the reflog and the way git works, that's actually quite difficult to do.

<comment><USER85> I learned that Git stores data as DAG at the very beginning when introduced to it. But I came to get clicked until I realized that it is not only a DAG but an _immutable_ one. That is, existing nodes of the DAG are never changed once created. The only operation supported by the system is more or less: _create_. Also, using the plumbings to peek into the content of the objects and refs inside the .git helps a lot as well.

<comment> black-tea Yeah, that's a very important point. Even changing the parent of a commit, that is, an edge in the graph, changes the hash of the commit. Therefore to change the parent (like in a rebase) you have to make a new commit, but the old commit doesn't go anywhere, you just can't see it because you have no reference to it any more.

Git will garbage collect these commits that can't be reached by any reference after a while, but usually that's long after you've forgotten they ever existed.

</comment></comment></comment><comment><USER86> This is very good explanation, but only explains what happens with the files, nothing about the graph what is a git repository. This talk helped me tremendously to finally understand what's going on in git: [https://www.youtube.com/watch?v=1ffBJ4sVUb4](https://www.youtube.com/watch?v=1ffBJ4sVUb4)

It is one of the best talks about git for beginners with an unfortunate title :D

Also, this interactive visual tool helped me to understand branching: [https://learngitbranching.js.org/](https://learngitbranching.js.org/)</comment>


In Discussion with Anna Fifield, Author of 'The Great Successor' - <AUTHOR> https://www.japantimes.co.jp/culture/2019/06/08/books/discussion-anna-fifield-author-great-successor/ <comment><AUTHOR> _The Divinely Perfect Destiny of Brilliant Comrade Kim Jong Un_

[https://cdn.japantimes.2xx.jp/wp- content/uploads/2019/06/p18...](https://cdn.japantimes.2xx.jp/wp- content/uploads/2019/06/p18-laflamme-fifieldqa-b-20190609.jpg)

</comment><comment><USER2> > After one story showing a copy of Kim Jong Un's Brazilian passport — chapeau > to the reporters at Reuters for getting that — the Brazilian foreign > ministry said it was investigating.

"chapeau to the reporters"?!?</comment>