IBM Open-Sources Power Chip Instruction Set - <AUTHOR> https://www.nextplatform.com/2019/08/20/big-blue-open-sources-power-chip-instruction-set/ <comment><USER2> I have so many questions:

\- Where can I get the ISA specification?[1]

\- Where can I get a compiler?

\- Is there a link to the "softcore model"?

With RISC-V you can start very simple and small (micro-controller) and work your way up in understanding and implementation to a very large core (application class). POWER is a monster of an architecture, designed more for "big iron". I guess that might limit the "hobbyist" factor RISC-V has.

1\. This I think, all 1200 pages of it: [https://openpowerfoundation.org/?resource_lib=power-isa- vers...](https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0)

<comment><USER3> I own a Talos II ([https://www.raptorcs.com/TALOSII/](https://www.raptorcs.com/TALOSII/)) computer. It actually runs an official port of Debian ([https://wiki.debian.org/PPC64](https://wiki.debian.org/PPC64)) on it, which includes a compiler.

<comment><USER4> I have drooled over the Talos II for quite some time...

Do you have a particular use case that makes POWER make sense over x86, or do you share my paranoia and love of non-mainstream ISAs?

<comment><USER5> Use of GPUs. Not Talos II it seems (?), but with POWER, GPUs are first-class citizens on the system, with NVLink-2-bus access to main memory as the CPU - 150 GB/sec in each direction! (simultaneously!)

<comment><USER6> Are all accesses to the memory from the GPU still checked for permissions at the hardware level by an IOMMU?

<comment><USER7> Yeah, checked for permissions in hardware, but not by an IOMMU. Requests from the GPU are forwarded to the "standard" SMMU. See [http://www.ieee- hpec.org/2018/2018program/index_htm_files/13...](http://www.ieee- hpec.org/2018/2018program/index_htm_files/135.pdf)

</comment></comment></comment></comment></comment></comment><comment><USER8> I'd like to recommend the friendly people at Oregon State University Open Source Labs [0] who host POWER resources for open source projects. If you're looking to see what the ISA can do on P8 or P9 system, I'd definitely contact them and see if you can get a VM.

There's also a cool vector library [1] that bridges the gap between different versions of the ISA and different compiler versions.

[0]: [https://osuosl.org/services/powerdev/](https://osuosl.org/services/powerdev/) [1]: [https://github.com/open-power-sdk/pveclib](https://github.com/open- power-sdk/pveclib)

<comment> tpearson-raptor Shameless plug, but you can so grab a POWER9 micro VPS (and large ones too) without any human intervention at integricloud.com . Those are commercial / paid though, not free.

</comment></comment><comment><USER9> An open, high end CPU design is really going to change the cloud market. An ISA like this is a first step in that direction.

Facebook and Google already have their own compute projects and, like Amazon, have access to custom versions of silicon from a variety of vendors.

With a properly open CPU design we'll start to see the first tightly integrated, vertical "cloud" products that maybe still have a "commodity" API on the top (or maybe not?) but are custom _all_ the way down from there.

With the end of Dennard Scaling, if not Moore's Law, Open ISAs and Open CPU designs will radically change both the hardware and compute markets and ecosystems over the next 5 to 15 years, similar to what we saw with Open Source in the 1990s.

Of course, it's not clear that POWER will be the one to do that, and RISC-V isn't going to be making a grab for Intel's crown any time soon, but this looks like IBMs bid to lead in that area.

When the cloud vendors start building systems like this they'll not look too much different from mainframes and IBM wants to continue to own that market.

<comment><USER10> It's a far, far cry from an open ISA to having multiple competing vendors, let alone open CPU designs.

It was much earlier, but OpenSPARC's impact was limited-- and that was full RTL.

If POWER is open, does anyone really want to make competing high-performance designs-- let alone open them? Better to take something like RISC-V and come up with the first high performance design.

This is especially true when you consider IBM's vertical integration: IBM is the only real POWER OEM and the only real POWER semiconductor vendor.

(If we really assume a reduction of innovation in processors, and a 15 year time horizon... expiration of IP becomes a significant factor, too. Why not just make generic ARM?)

<comment><USER11> "Better to take something like RISC-V and come up with the first high performance design."

The problem is that RISC-V mnemonics and programming model is so retarded (as compared to MC68000 or UltraSPARC) that one needs a compiler to abstract and hide that mess away. The other problem is that in several years in which RISC-V has been hyped, nobody came up with a 19" rack server design, let alone sold one priced competitively with a 1U P. C. tin bucket server. RISC-V is all hype, but without serious hardware, its impact will be and remains questionable at best.

<comment><USER12> > mnemonics and programming model is so retarded

Could you provide some examples instead of a slur?

<comment><USER11> move dst, src, src -- I could stop right here, but wait, there is more!

lui, auipc -- because two instructions are better than a simple move.b or move.w. Really, what nonsense.

sx, ux - I'm speechless at that nonsense.

bltu, bgeu -- because blt and bge just weren't enough -- who designs a processor like this?

lb, lh, lhu, lbu, sltiu instead of move.b, why? I challenge the sales pitch of making more nonsensical instructions amounting to a simpler processor design! (Boy does this make me mad.)

It's not a slur, it really is utterly retarded, especially if one used to program an elegant microprocessor like the UltraSPARC or the Motorola 68000; even the MOS 6502 is more elegant.

But to each his own, live and let live, right? Well why then must this botched processor constantly be sold and paraded as the greatest thing since sliced bread, a non plus ultra of processors, when it isn't?

<comment><USER13> Plenty of HN readers have children with severe learning disability. Using the word "retard"[1] is likely to attract downvotes.

[1] Unless you're talking about progress or watch mechanisms.

<comment><USER11> That's exactly what I'm writing about, progress. RISC-V is not an advancement. What is opposite of advancement? In a system, it's either regression or retardation.

And expecting people outside of the Puritan U. S. to abide by the same political correctness norms is extremely rude, inconsiderate and exclusionist -- using those same politically correct norms no less, which is to say, the U. S. should ban political correctness, and do so yesterday for the benefit of everyone.

<comment><USER13> I don't care what words you use. I'm just telling you that when you describe people as retards you're going to get downvotes, and I'm telling you why that is.

I'm not American and I don't live in the US.

<comment><USER11> I didn't describe people as retarded, but their work. Even very smart people often do dumb things.

<comment><USER13> When you say things like this...

> mnemonics and programming model is so retarded

...you are going to get downvoted. This is because people who speak English as a first language understand you to mean "this is stupid, like a retard". They don't understand you to mean "this is delayed, like a watch mechanism would be adjusted".

You can keep arguing that you didn't mean what you said, but at least two people are telling you how your words are being interpreted.

<comment><USER11> ...you are going to get downvoted.

I would be a sad excuse of a being if I feared what some people on a random forum will think of me, or "downvote" me in some arbitrary, imaginative system. The entire thing is a delusion.

Not singling out anyone in particular but I'm a formed adult and have been for several decades, and I do not require upbringing, id est, anyone telling me how to behave or what not to write.

I will write it how I want and I shall not fear arbitrary decisions based on some arbitrary policies someone somewhere thought up. If that gets me down- voted or even banned, I will not let it bother me, as life does not revolve around arbitrary websites trying to tell one how to behave and think and I will damn myself into oblivion before I allow someone to impose such a thing on me. Lest we forget: I'm the only one who decides that, and I'm not allowing anyone to control my thinking or writing.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Will this do any better than open source SPARC, which was open sourced in 1999?

[https://www.eetimes.com/document.asp?doc_id=1140292](https://www.eetimes.com/document.asp?doc_id=1140292)

<comment><USER15> I can't see why it would. This would have mattered 20 years ago when there weren't more compelling ISA's out there. But that's not today's world: ARM is fairly ubiquitous and dirt cheap while RISC-V is a promising and open source up-and-comer. This seems like a relatively non-event (or worse: confirming that it's effectively a dying/dead platform) unless one has a significant investment in Power.

<comment><USER16> Except neither of those are in the same performance ballpark as Intel, while Power ISA is.

<comment><USER17> I might be misunderstanding you, but performance isn't in the ISA, it's in the implementation. In fact, the x86 ISA is the best example for this: It's really difficult to get competitive performance out of an ISA designed in the 70s, yet billions upon billions of USD in R&D and optimization make it work.

<comment><USER18> The ISA matters, otherwise we wouldn't care about SIMD. If your ISA is missing SIMD functionality, then it doesn't matter how good your implementation is, it will be slower than an implementation of an ISA that supports SIMD when it comes to anything that can leverage SIMD.

</comment></comment></comment></comment></comment><comment><USER19> I like it.

Back in the day IBM ran a "System on Chip" factory based on PowerPC that gave us the Bluegene/L supercomputer, the GameCube/Wii/Wii U, the Playstation 3 and the Xbox 360. All of these combined one or more cores, coprocessors and tweaks to hold its own against x86.

RISC-V is meant to be used like that, but memory management support is not yet finalized. They are sampling prototype RISC-V chips with an MMU you can put in a dev box to develop Linux on. Other than that you are not using Linux or Windows.

If you think mainstream OS is bloated, then RISC-V has your number. If you want very low cost it would be exciting to cut RISC-V down to have fewer and less wide registers. The other day I saw an article about a guy who wants to build RISC-V out of vacuum tubes and thought... 'cripes with all of those wide registers it is a lot of tubes.

POWER is good-to-go right now for high end applications and can stay relevant against ARM and x86 by staying open.

</comment><comment><USER11> They are misunderstanding why RISC-V and Raspberry Pi are popular: it's not so much that they're freeware but that they are cheap. Very few people in IT know how to implement processors in hardware even with an FPGA. What makes a processor popular are cheap, affordable systems people can easily acquire in an online shop at prices which compete with or are below contemporary P. C. tin bucket hardware.

If IBM wants an uptake of POWER systems and people to develop on them and for them, the only thing which might make a dent are sub-$500 USD complete workstations and rack mountable servers. Otherwise, they will repeat the same mistake which _Sun_ made, that is, they open sourced their UltraSPARC T1 under GNU GPL but the uptake was nil, because few had the knowledge to design systems around the processor. People want cheap, ready made toys they can tinker with immediately.

</comment><comment><USER20> Not a problem with the article but when it lists the various past contenders, MIPS (with many times the lifetime installed base of, say SPARC, and still in active production) doesn't get a mention. MIPS's IS has also been recently open sourced. It's a cautionary tale.

I don't see the point of this effort for IBM. These things need communities, and POWER simply doesn't have the community; as a proprietary architecture for so long that nobody really decided to buy POWER but rather they wanted some device/ecosystem/price point and POWER was how IBM could deliver it.

The article mentions RISC-V, which still has a nascent ecosystem and no significant design wins (yet!!). But if you want to design a chip with it you can find designers with some experience with it, people developing some IP you might want to use, etc. Even that has more momentum.

</comment><comment><USER21> Naive questions:

\- Will Huawei be able to use this processor design (now that it is open sourced) to build it's own chips, bypassing ARM restriction & US IP ?

\- Are these processor designs usable in mobile device, or only in workstations and servers (using to much power for example) ?

<comment><USER22> IBM targets the scale-up market (few big, fast machines) with POWER instead of scale-out (many small, slower machines). Consequentally they are high performance but not particularly tuned for high efficiency, because performance is the more important design goal of the system.

<comment><USER23> [https://en.wikipedia.org/wiki/PowerPC_e6500](https://en.wikipedia.org/wiki/PowerPC_e6500)

Freescale hasn't made a new low-power Power chip in a while, but... historically speaking, there were a lot of low-wattage / efficiency-focused embedded POWER designs.

I don't know what happened politically between the companies to use ARM instead. But I would imagine that ARM's instruction set was cheaper (or maybe easier) to engineer than Power ISA. Hopefully Freescale engineers can chime in on the discussion, because I'm really just shooting from the hip here.

I would expect most issues to come down to business politics. IBM open sourcing the PowerISA is also a business politics move (I guess they hope to recapture the lost ground in the embedded space).

PowerISA means operating with IBM's ecosystem: GCC, Linux, etc. etc. Remember IBM has merged with RedHat, so there's a lot of promise for Linux support that ARM and RISC-V don't necessarily provide. I think this is a good move.

<comment><USER24> > promise for Linux support that ARM and RISC-V don't necessarily provide

uh, ARMv8 and RISC-V were developed with Linux in mind from the beginning, they didn't even _have_ anything other than Linux/BSD/various-RTOSes, like IBM did with AIX.

<comment><USER23> That's not the kind of support I'm talking about.

Who is writing the RISC-V compiler? If the RISC-V compiler for GCC or CLang messes up, who do you call?

If the Power9 GCC / CLang compilers mess up, you call Red Hat for support. Red Hat / IBM are now the same company, so they'll offer end-to-end services.

\</comment></comment></comment></comment></comment><comment>-----

ARM has okay support: the ARM foundation seems to be taking care of their compiler kits / Linux patches / etc. etc. pretty well. But I don't think you can buy an ARM support package from anybody... really.

I think the ARM / Linux ecosystem is still nascent. You get good support through the Rasp. Pi community, and maybe the occasional Android Phone gets a big community around it. But ARM / Linux ecosystem is quite poor outside of Rasp. Pi.

ARM, as a company, is clearly designed as an "embedded" company. It provides the documentation and compilers, but doesn't provide too many OS-level services above that.

<comment><USER24> > If the Power9 GCC / CLang compilers mess up, you call Red Hat for support

uh, where and when exactly did they offer that? Actually I don't remember anyone anywhere offering commercial support for GCC or LLVM/clang.

Well, I'm not the type of person to look for commercial support for anything ever, but I've heard of several companies that provide support for DBMSes like PostgreSQL. Not so for compilers.

I just googled "gcc commercial support" and the results are the GCC FAQ, a mailing list post about it from 2005 (!), GCC on Wikipedia, "Office 365 GCC" (lol) and so on. Looks like it's just not a thing at all.

<comment><USER23> Sorry, not GCC / Clang. You're right.

But IBM's XL Compiler: [https://www-01.ibm.com/support/docview.wss?uid=swg21110831](https://www-01.ibm.com/support/docview.wss?uid=swg21110831)

\</comment></comment></comment><comment>-

I think I confused it with ARM: ARM has a CLang-based compiler with official ARM support IIRC. [https://developer.arm.com/tools-and-software/server-and- hpc](https://developer.arm.com/tools-and-software/server-and-hpc)

I think the hobbyist (who won't get much support even if they're a paying customer) benefits from free tools / free support / communities.

But it seems like a number of professionals prefer having a degree of professional support in the products they use.

</comment><comment><USER25> Interesting move by IBM.

See also OpenSPARC. [1]

I'm curious if anyone will do anything interesting with this.

[1] [https://www.oracle.com/technetwork/systems/opensparc/index.h...](https://www.oracle.com/technetwork/systems/opensparc/index.html)

</comment><comment><USER26> The IP/patents was doomed to expire anyway. But hey they got a free PR stunt out of it.

Anyway it will be interesting what "non expired" patents they bundle with this. Mostly because of [https://archive.fosdem.org/2019/schedule/event/patent_exhaus...](https://archive.fosdem.org/2019/schedule/event/patent_exhaustion/)

which would allow people in the US to use these patents in any context as long, they derived their worked from an Open Source Power processor which got the patents exhausted and did not violate the Open Source license the processor.

</comment><comment><USER27> 3 of the top 11 supercomputers in this years ranking are Power-9s.

</comment><comment><USER28> Still waiting for that modern POWER9 based laptop with 7-row classic ThinkPad keyboard ...

</comment><comment><USER29> How is does this different from publishing the _instruction set_ , which was presumably already available (if it weren't, how would one write an application for it)?

<comment><USER30> I guess, publishing something does not necessarily mean making it public domain.

<comment> tpearson-raptor Right. For instance, the x86 architecture is published. If you try to build anything that can interpret it, you'll get sued by Intel or AMD (or both, if you really copied anything good).

What is less widely considered is that emulation is considered an implementation of a CPU. So e.g. research labs at universities have been told in no uncertain terms by CPU vendor legal notices to stop working on research that is emulating the x86 or ARM instruction sets. Now with the POWER ISA being open, everything about the ISA is fair game for research in emulation, soft cores, hardware, etc., which does put it in a space that only academic "toy" ISAs and RISC-V really sat in before.

<comment><USER31> But we have qemu [0] that emulates quite a lot of Instruction Sets. How comes that it is allowed to exist, qemu is emulating quite a lot of instruction sets [1] ?

[0] [https://www.qemu.org/](https://www.qemu.org/)

[1] [https://wiki.qemu.org/Documentation/Platforms](https://wiki.qemu.org/Documentation/Platforms)

<comment> tpearson-raptor The support is there, yes, but it's always been a grey / largely unenforced black area. As soon as the emulator cuts into chip sales in any significant way the tolerance for its use would stop.

IANAL, this is simply what legal folks are saying on this topic.

</comment></comment></comment></comment></comment><comment><USER32> If only this had happened as Opteron was taking a beating in the server market.

Now with EPYC Rome, I wonder just how many takers IBM will have.

<comment><USER33> There seem to be general paths for OS.

1) OS from the start. Develop in the open. Maybe lock some features behind a paywall.

2) OS when something is not hot anymore. Take your formerly private stuff you charged a lot of money for, and because so much better stuff has come out.. meh, let's OS it.

This is clearly a case of #2....

<comment><USER34> While I agree that there's a whiff of IBM trying to offload responsibility for older tech, I think some credit has to be given to projects which pre-dated the current industry attitudes towards open source. A lot of things had to happen (probably including people of a certain generation/era passing the torch) before companies felt comfortable with the idea that they could open source their tech, and still have a competitive advantage over anyone else who would use it.

In the late 80s/early 90s when POWER appeared, and RISC fever was in full swing, if someone, as a VP or C-suite level decision maker at a mega-corp like IBM, declared "let's just release all the IP of our high performance processor design to anyone who wants it!", they would have their coworkers and superiors questioning their sanity, at very, very least.

<comment><USER35> > if someone, as a VP or C-suite level decision maker at a mega-corp like IBM, > declared "let's just release all the IP of our high performance processor > design to anyone who wants it!", they would have their coworkers and > superiors questioning their sanity, at very, very least.

Well that was basically the PPC consortium. I'm not sure how much apple/motorola/etc paid to be part of it, but the idea was to build a common ISA from multiple vendors.

</comment></comment></comment></comment><comment><USER36> I'm afraid the are doing it at least 10 years too late.

</comment><comment><USER37> Naive question: What would this mean for Xbox 360 emulators?

<comment><USER38> As someone writing a 360 emulator, probably not much. The Cell docs are already available (Xenon is a modified Cell PPE), and the ways that it's different are a one off for Xenon that probably won't be documented in this dump.

</comment></comment><comment><USER39> IBM is dead until it gets Z mainframes and Power servers in big a three data center (AWS, GCP, Azure).

Guessing Microsoft will start with putting mainframes in the West Des Moines data center since so many insurance companies are still dependent on DB2 batch crunching.

<comment><USER40> > IBM is dead until it gets Z mainframes and Power servers in big a three data > center (AWS, GCP, Azure).

Google _is_ using POWER9 servers in their data centers:

> > [https://www.forbes.com/sites/patrickmoorhead/2018/03/19/head...](https://www.forbes.com/sites/patrickmoorhead/2018/03/19/headed- > into-its-fifth-year-openpower-has-momentum-into-the-power9-generation/)

> [https://www.nextplatform.com/2018/03/26/google-and-its- > hyper...](https://www.nextplatform.com/2018/03/26/google-and-its-hyperscale- > peers-add-power-to-the-server-fleet/)

Of course, most of their servers are still x86; as far as I am aware, the reason why Google also uses POWER9 servers is that they don't want to be _too_ dependent on the two manufacturers of x86 CPUs.

</comment></comment><comment><USER41> might be too little too late.

I used to be powerpc developer myself, now nearly all the communities, the ecosystem, the core developers are gone, it's beyond repair, sigh.

</comment><comment><USER42> Phoronix ran benchmarks and current Talos II systems run hotter and slower than equivalent x86 systems but maybe they will improve over time.

<comment><USER43> AFAIK those benchmarks weren't specifically optimized for that processor architecture. Most programs are optimized with x86 systems in mind. The results for your specific application might come out differently.

<comment><USER44> Cases in point: [https://sthbrx.github.io/blog/2018/08/15/improving- performan...](https://sthbrx.github.io/blog/2018/08/15/improving-performance- of-phoronix-benchmarks-on-power9/)

</comment></comment></comment><comment><USER35> Does this include the system IP? I asked that question when openpower started, and it took a number of years before any of that started to show up. Even now, i'm not sure its all there.

Its pretty hard to build a reasonable/compatible machine when you have to "reinvent" the interrupt controller/iommu's/etc.

</comment><comment><USER45> That article statues:

>"No one is saying that the OpenPower Foundation will have an easy time growing its ecosystem, despite the many architectural advantages that Power holds over other ISAs ..."

Could someone elaborate on what some of those "architectural advantages" over other ISA are exactly?

</comment><comment><USER43> Is there a second independent manufacturer for Power processors?

<comment><USER15> NXP/Freescale

<comment><USER24> Did they ever make anything faster than the 4-core QorIQ chip that powerpc- notebook.org is using?

Current NXP networking chips are ARM Cortex based, like the LX2160 that's in the upcoming SolidRun workstation (which they still haven't publicly demonstrated ECAM PCIe on, sadly…)

<comment><USER46> Their very first of the T4 series was 12 core / 24 thread 64-bit e6500 based (T4240).

</comment></comment></comment></comment><comment><USER47> Interesting. I would like to take a look at that softcore model.

</comment><comment><USER48> What does it mean to open source an instruction set? What can we do now that we couldn't earlier? (genuine doubt)

<comment><USER49> Probably means they wont sue you or bill you if you use it in your own processor designs. The article mentioned releasing a softcore for FPGA; that at least means you can run the instruction set on something. There are even enthusiasts that might be interested in using an FPGA to build a whole computer; for example the Amiga community have a PowerPC based operating system. Instruction sets must also be an acquired taste; Power seems complex to me; but a lot of people clearly like it.

</comment></comment><comment><USER50> 28 years after introduction. A bit late.

</comment><comment><USER51> Use xlc once. I'm done thanks.

<comment><USER52> Why in the _world_ would you use xlC, unless you're masochistic enough to target IBM-AIX? PowerPC is a very well supported architecture, supported by common compilers and operating systems.

<comment><USER35> For the same reason people use icc, it generates faster code.

A couple of years ago I compiled part of the application I was building for power8. The perf was pretty bad, so I rebuilt parts of it with xlc, and it was literally over 2x faster. That made the machine competitive/faster than the x86's we were using.

Now GCC/clang have bee getting better and the gap with icc is nearly closed. I'm not sure how much of that applies to xlc, but i'm betting there hasn't been nearly as much work optimizing for POWER as there has been for arm and x86.</comment></comment></comment>


The life cycle of HIV in 3D [video] - <AUTHOR> https://blogs.scientificamerican.com/observations/watch-the-life-cycle-of-hiv-in-colorful-new-detail/ <comment><USER3> As a technologist, I have mixed feelings when I see the fascinating details of life. On one hand, mastering this molecular machine would give us literally God-like powers: we could fabricate, grow or heal anything. We could solve all current problems, we could terraform planets using a few milligrams of DNA and literally redefine what it means to be human.

On the other, I see the human body as a completely unsecured cybernetic system, that can be so easily tricked to pick up any random bit of programming and insert it into it's own code. There is no forethought or design, no rational defense, just good enough systems that have evolved randomly against non-rational adversaries that happened to emerge out of the protein soup surrounding us.

The troubling fact is that mastering the wondrous biomolecular machine necessarily comes with the power to kill every human on the planet. Truly God- like powers.

<comment><USER4> > power to kill every human on the planet. Truly God-like powers.

You can't really design a perfect virus that will wipe out the human race, because anything you do to affect its properties will also affect its ability to spread. I'd be way more concerned about the destructive power of nuclear weapons, still numerous enough to destroy a very large part of humanity and our vital infrastructures.

<comment><USER3> Are you sure you aren't still thinking in the conventional, evolutionary paradigm?

A highly engineered bioweapon could circumvent such problems by separating the infection phase (which could be completely silent and airborne) from the eradication phase. The payload could be triggered deliberately at a later date when a certain secret artificial protein is released in the environment - <USER2> then produced in industrial quantities by infected hosts. Or maybe airdropped over areas that should be cleansed.

And that's just scratching the surface of what's conceptually possible. It could trigger specific ethnic characteristics or individuals, it could set up exotic cyber-hybrids like public key decryption in DNA for commands from its command and control. It could create side channels among infected hosts, for example by triggering minute anatomical modifications in the inner ear and the vocal centers, making them able to send and receive ultra- or infrasounds controlled by the mallware.

As a more subtle cyberattack, an infected individual could grow a whole parasitic subsystem that extracts select visual and auditory data and stores them in DNA memory for later broadcast.

<comment><USER5> Wow these are novel concepts, do you read a lot of sci fi? How did you come up with these interesting scenarios?

<comment><USER3> I'm not really inspired by scifi - but I'm sure some authors have had similar and probably much wilder ideas.

Been thinking for years about the human body as a cybernetic attack surface with no engineered cyberdefense. Most people seem not able to make that mental leap; no, the human body can't behave like a vulnerable Windows 95 machine giving kernel privileges to any ActiveX control it can download, because reasons.

But once you see the biological world like a hacker and DNA like a programming medium, as opposed to a representation of what evolution produced, an endless array of nefarious possibilities become obvious. The rational power of our minds far exceeds what evolution could ever concoct - or defend against.

</comment></comment></comment></comment></comment><comment><USER6> I think articles like Ken Shirriff's "Cells are very fast and crowded places"[1] are good companions for visualizations like this. It helps to keep in mind that the things moving around in cells are flying around at break-neck speeds if you scale them up linearly.

1 - [http://www.righto.com/2011/07/cells-are-very-fast-and- crowde...](http://www.righto.com/2011/07/cells-are-very-fast-and-crowded- places.html)

<comment><USER7> Where "flying around" means "constantly bumping into everything else". This means small stuff doesn't just fly around the cell, it has to _diffuse_ through it. A nice side effect is that eventually, everything gets into contact with everything else. That, as I understand, is how small molecules get to their right place.

Also, this means that it's too tight for large stuff to move around at all. Hence the specialized machinery within the cell that transports large molecules.

Source for both: I'm 1/3d of th way through The Machinery of Life[0]. Incidentally, I learned about this book from HN. It's absolutely amazing. The biggest selling point are the drawings - David S. Goodsell created a lot of illustrations (like these[1]) that give you a good perspective on how stuff is packed within cells.

EDIT: that blog post you linked covers the diffusion aspect well, I second the recommendation to read it.

\--

[0] - [https://www.goodreads.com/book/show/6601267-the-machinery- of...](https://www.goodreads.com/book/show/6601267-the-machinery-of-life)

[1] - [http://mgl.scripps.edu/people/goodsell/illustration/public](http://mgl.scripps.edu/people/goodsell/illustration/public)

</comment></comment><comment><USER8> Absolutely insane how this is actual reality. That millions of people have died from such a small object that seems to have more creativity and complexity than I've ever seen.

<comment><USER9> You might enjoy: Influenza A (H1N1) – How many bits does it take to kill a human? [https://www.bunniestudios.com/blog/?p=353](https://www.bunniestudios.com/blog/?p=353)

<comment><USER10> Also, video: [https://www.youtube.com/watch?v=NPr-i- IbA7s](https://www.youtube.com/watch?v=NPr-i-IbA7s)

This one is about Influenza: [https://www.youtube.com/watch?v=7Omi0IPkNpY](https://www.youtube.com/watch?v=7Omi0IPkNpY) (not H1N1, but quality is better)

I learned a lot today (At least that's what I felt) LOL

</comment></comment></comment><comment><USER11> The amazing part for me was that virus "code" automatically finds the unrelated host "code" in what is effectively an equivalent of space travel inside a host body, does copy and paste to insert itself somewhere in host code and everything just works! I can't think of any of our computing models that is capable of doing this and so robust at errors.

<comment><USER12> Lisp

</comment></comment><comment><USER13> I know it's just my own biased anthropomorphizing but the virus almost looks sinister and intentional in its actions.

<comment><USER6> The music really helps with that. The video gave me a spooky feeling.

<comment><USER13> Ha, I didn't even watch it with sound. Will have to do that when I get home.

</comment></comment></comment><comment><USER14> I would love to know how this animation was made. Is there any sort of simulation happening?

<comment><USER15> It's two separate things, both mentioned in your question: simulation then animation. Both steps are computationally expensive enough that they can't be done in one run.

For simulation, typically a molecular dynamics code is used along with features specific to biological analysis (since MD by itself is a physics simulator). NAMD is one of the well-known MD tools used for bio work. Depending on the complexity and features/accuracy sought, a whole host of other tools might be involved. The timeframe of simulation is of the order of weeks to months given massive computational power (e.g., a large allocation on one of the national supercomputing grids).

Once tons of simulation data is generated (as the output of simulation), then 3D visualization tools can be used. NAMD has a sister vis tool called VMD. Blender is another option. Incidentally, Janet Iwasa (the narrator and researcher behind this work) is a visualization expert, so it's likely she only worked on the second step (animation) by using existing simulation data, or collaborating with a simulation group. (Again the computation required for rendering is very high, on the order of days to weeks using a large allocation on a supercomputer).

</comment></comment><comment><USER16> Makes one really wonder just what, exactly, is out there mindlessly gobbling and reproducing itself in an endless quest to just keep going. Puts human life in perspective too. We're all just mindless gobblers when zoomed out enough.

</comment><comment><USER17> Hard to believe that no one has programmed this. Evolution is insane.

<comment><USER18> Seems that you are not a programmer. Even with Intelligence people can write code (much much simpler and buggy) how can chaos build such a complex thing? Can you answer what was first? information (RNA/DNA) or the first cell?

<comment><USER17> What makes you think I'm not a programmer? I was marveling at how evolution can lead so something so systematic.

> Can you answer what was first? information (RNA/DNA) or the first cell?

No I can't. What are you getting at?

</comment></comment></comment><comment><USER19> Question. How is that even knowing the lifecycle of HIV at this level of detail, there is not a cure for it?

<comment><USER10> I Googled it for you:

[https://www.ted.com/talks/janet_iwasa_why_it_s_so_hard_to_cu...](https://www.ted.com/talks/janet_iwasa_why_it_s_so_hard_to_cure_hiv_aids)

[https://www.seeker.com/will-we-ever-cure- hiv-1792546668.html](https://www.seeker.com/will-we-ever-cure- hiv-1792546668.html)

[https://en.wikipedia.org/wiki/Management_of_HIV/AIDS](https://en.wikipedia.org/wiki/Management_of_HIV/AIDS)

Also you may interested:

[https://en.wikipedia.org/wiki/The_Berlin_Patient](https://en.wikipedia.org/wiki/The_Berlin_Patient)

<comment><USER20> >in the U.S. HIV kills 10,000 people per year

I remember an early passage from Buckminster Fuller's Grunch of Giants where he tells the reader to visualize fully packed stadium and explains that's what 10,000 people looks like.

<comment><USER21> I'm not sure 10,000 packs a stadium in the US. Maybe the bleachers of a high school football stadium.

</comment></comment></comment></comment><comment><USER22> When I see the animations I can't stop thinking about a Turing machine. How it works in a similar fashion, copying symbols to keep track of the program while generating the result in the process.

It will be nice to know if you can build a Turing complete machine using DNA and the cellular mechanisms. [https://www.quora.com/Is-DNA-a-Turing- machine](https://www.quora.com/Is-DNA-a-Turing-machine)

</comment><comment><USER23> Here's the video on vimeo [https://vimeo.com/260291607](https://vimeo.com/260291607)

</comment><comment><USER24> Related to this type of animation, there is a great book called "The Machinery of Life" that talks abut molecular level biology with amazing illustrations. [https://www.amazon.com/Machinery-Life-David-S- Goodsell/dp/03...](https://www.amazon.com/Machinery-Life-David-S- Goodsell/dp/0387849246)

</comment><comment><USER25> A better animation is the winner of the AutoPACK challenge few years back: [https://vimeo.com/62635232](https://vimeo.com/62635232)

Those guys did an awesome job because: a) use of brownian motion b) sick af music.

<comment><USER26> That's a poor visual of Brownian motion. Things don't giggle they randomly fly around at ~250 miles an hour.

It's still a great video just IMO misleading in its own way.

</comment></comment><comment><USER27> Mindblowing. To think that chance+time produced something like that is staggering.

<comment><USER28> +reproduction +selection

<comment><USER29> I haven't yet seen a good explanation as to why this focus on randomness is so prevalent, but chance really is almost irrelevant when it comes to evolution.

The main mechanisms of reproduction and selection that you point out have almost no randomness at a population level.

Selection of individuals has some randomness associated with it, as death can come unexpectedly to anyone, but at population levels it is the genes that make it more likely for an individual to survive/pass on their genes that are the ones that get passed on. It's possible that an entire population gets wiped out, or a particular gene gets wiped out due to chance, but as long as the population is reproducing then on average the genes that are passed on are the ones that help the population survive.

Similarly reproduction isn't random at population levels either. Sexually reproducing populations mix their surviving genes evenly within geographical locations over evolutionary timescales (such as trees), or selectively if individuals choose their mates (like humans!). Neither of those things are random. Mutations that happen during reproduction are somewhat random but, as for asexual populations, the amount of mutation at the population level is not random. It's reasonable to expect the reproductive mechanisms to be selected for in such a way to maintain coding errors and the like (at an appropriate level) so that mutations continue to develop and strengthen the gene pool.

While there are lots of single events where randomness and chance come into play, as soon as you have a collection of things that reproduce those things must either get better at reproducing or cease to exist. Chance has nothing to do with it.

<comment><USER30> ENTROPY BABY.

</comment></comment></comment></comment><comment><USER28> Living in 2018 is quite a privilege. Most microbiologists who spent their lives trying to puzzle this out won't get to sit back and watch the answer.

</comment><comment><USER5> This is why I'll never go on tinder or screw around, frightened about getting stds. My friends act like STDs are no big deal and joke around about the times they've contracted chlamydia and gonorrhea etc like it's a cost of doing business (getting laid).

I'll stick to long term relationship.

</comment><comment><USER31> Amazing! So there is self-replicating, self-modifying code (HIV quickly mutates to avoid detection) code, that sometimes jumps into middle of an instruction (GAG proteins being cut into the enveloping proteins).

</comment><comment><USER32> Wow that gives me shivers, creepy.

</comment><comment><USER33> That looks scary. VERY scary!</comment>


Apple Watch has found a surprisingly useful home with service industry workers - <AUTHOR> https://qz.com/1282210/the-apple-watch-has-found-a-surprisingly-useful-home-in-the-service-industry/ <comment><USER2> I can't believe I've never considered just how valuable it would be in these scenarios. Another reminder about how vast our blind spots (and those of us tech workers' so-often-not-very-diverse teams) can be. If I were spending hours at a time away from my phone, I'd value wrist notifications so much more than I do at my desk job.</comment>


Watson Speech API in June - <AUTHOR> http://techcrunch.com/2012/04/19/att-opening-watson-speech-recognition-to-developers-with-new-apis-in-june/

<comment><USER2> I feel that the category specific speech recognition will help accuracy compared with a general service like Siri.

On a separate note, how does one go about creating a speech recognition backend like this? A point in direction would be helpful. Thanks!</comment>


What I Learned from a Week of Shitposting on LinkedIn - <AUTHOR> https://www.linkedin.com/pulse/what-i-learned-from-week-shitposting-linkedin-kyle-coberly/ <comment><USER2> I read the post and knew it was satire after a couple sentences. i also realized: this is not a person I'd ever want to work with. thanks, you saved me time!</comment>


Frequency Analytics – open source private web analytics server - <AUTHOR> https://github.com/frequencyanalytics/frequency <comment><AUTHOR> Hey HN, we're releasing our version of self-hosted web analytics here. Very happy to take feedback or questions in this thread. Thanks for checking out our project!</comment>


The world's top economists just made the case for why we need English majors - <AUTHOR> https://www.washingtonpost.com/business/2019/10/19/worlds-top-economists-just-made-case-why-we-still-need-english-majors/ <comment><USER2> The decline in English majors precedes an overall decline in college attendance, I hope. Regarding STEM long term prospects, well, a lot of graduates there simply aren't very good. Rigorizing standards would lower the STEM unemployment rate. But every school's got to make a buck.

Maybe instead of English majors, these kids could spend a stint in the military. Or join an orchestra. Or work in sales at a car dealership. Something that involves developing a skill and exercising discipline.

<comment><USER3> To imply that the pursuit and achievement of an English undergraduate degree confers absolutely zero benefit or skill (or that everything even needs to be a "skill", but that's another conversation) is inaccurate at best. The ability to parse complex written information/documentation and distill value from it as well as to clarify your own thoughts in writing and communication is absolutely valuable and enriching for an individual.

Though I could very well be wrong and it is an absolutely useless degree, after all, I majored in philosophy ;)

<comment><USER2> You can train people in reading and good writing far more efficiently than an English degree. Edit: And I'd value students who take their study more seriously a lot more, but most are just third-rate students at third-rate schools getting a piece of paper.

</comment></comment></comment><comment><USER4> This is all nonsense. You know, it's like when we say communication is important in the workplace. I don't want to replace my engineer with a communications major. I want all the engineering prowess and the communication skill multiplies that effectiveness. If I get a comm major I get engineering prowess of zero multiplied by some amount of comm skill and that's useless. I don't want that.

</comment><comment><USER5> This arguments in this article aren't convincing.

Having well rounded citizens is good, but I don't think that means we need more English majors struggling to make a living.</comment>


A Neural Architecture Able to Learn and Communicate Through Natural Language - <AUTHOR> http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0140866 <comment><USER2> _The first example involves counting skills, ability to compare small numbers, ability to associate the words "your friend" to a known person, ability to retrieve information about her age from the LTM, ability to use personal pronouns._

Leaving aside the bit about learning to count, I don't see that the paper shows how the system displayed any 'ability to associate the words "your friend" to a known person'.

The input to the system that represents said friend is a set of phrases:

 _As the system has no sensory input, apart from that provided by the text- based interface, all the information must be provided in the form of input sentences._

In particular, the information about the friend in question is in the form of sentences:

 _The sentences of this dataset have been prepared by personifying the system in a four years old little girl in her social environment, which includes the two parents, a sister, a friend, two cousins, the four grandparents, two aunts, two uncles and six other children, for a total number of twenty persons._

At best they showed their system can recognise sentences that refer to a specific person, but recognition, or knowledge, of an actual person, is going to take a lot more than that.

To be honest, I don't think they show anything else than an elaborate natural language interface to a database.

</comment><comment><USER3> github link

[https://github.com/golosio/annabell](https://github.com/golosio/annabell)</comment>


Asustek: $200 Eee PC coming in 2009 - <AUTHOR> http://news.cnet.com/8301-17938_105-10080626-1.html <comment><USER2> The logical consequence of the fact that PCs keep getting faster even though a PC from 2005 did everything most people need (word processing, email, web, chat).

And Microsoft didn't see it coming, apparently.

</comment><comment><USER3> We'll get the $100 laptop and it won't come from OLPC. Profit makes the world go 'round.

<comment><USER4> Maybe not.... inflation alone could make that psychologically important 100$ mark impossible to reach if they don't get to it soon.

</comment></comment><comment><USER5> Bought my nephew (13) the eepc 900 in August, in late September it failed suddenly, they're sending it back under warranty. Hope it works better when it comes back...it's a nice little computer though.

<comment><USER6> An electronic device _failed_?! That never happens! You are surely the first person to ever experience this!

Sorry, what I meant to say was: What does this have to do with the article?</comment></comment>


Which country has the best brains? - <AUTHOR> http://www.bbc.co.uk/news/magazine-11500373

<comment><USER2> Measuring brains by number of Nobel prize winners is a bad idea. Modern science is heavily dependent on funding and scientists from developed countries have more opportunities here.

As an example take this year's winners in physics. One of them is British citizen and one has a citizenship of Netherlands. An interesting fact is that both of them were born (an made their first steps in science) in Russia. Are these brains Russian or British/Dutch?

<comment><USER3> I find it interesting that the worlds 2nd and 3rd largest economies, one of which has the worlds largest population, aren't even on the list.

<comment><USER4> They probably have their own equivalent to the Nobel prize.

</comment></comment></comment><comment><USER5> Nobels _per million people_ (population figures from putting "population of X" into Google):

US 1.05; UK 1.91; Germany 1.25; France: 0.91; Sweden 3.04

The ordering is very different from the BBC's (12345 -> 52314). I wouldn't be at all surprised to find that you get quite a different top 5 this way too.

<comment><USER6> Thanks, my immediate reaction to the article was that data normalization was not done. Now with normalized numbers, how 'bout that Swedish nepotism? :)

</comment></comment><comment><USER7> What sets America apart is we welcome innovative thinking and fund it more than any other country.

We have private and public institutions that put down the momey for these people.

This creates organic innovation, but also attracts the best minds to our country, who later turn into citizens.

</comment><comment><USER8> I don't think the peace prize should be counted if one is writing on countries with the "best brains". My understanding is that people who win the peace prize are usually ones fighting an oppressive regime, which is commendable, but not a huge intellectual feat.

<comment><AUTHOR> On the contrary, it is quite an intellectual feat to lead a large group of people against a powerful oppressive regime. It gets quite difficult as the organization grows and everyone has their own agenda.

</comment></comment><comment><USER9> I'm disappointed this wasn't some tongue-in-cheek zombie guide.

</comment><comment><USER10> Given the US/UK's current economic predicament it hurts that they are first/second on economic 'bels.

<comment><USER11> If we could get the smart people (physics, etc. graduates) from financial- masturbatory zero-sum games on wall street back to productive scientific and engineering enterprises, I'd feel a lot better about things.

</comment></comment><comment><USER12> that was one confusing chart</comment>


Healthcare.gov crashes on the last day before deadline - <AUTHOR> http://techcrunch.com/2014/03/31/healthcare-gov-crashes-on-the-last-day-to-enroll-before-the-deadline/ <comment><USER2> How exactly is this fine supposed to be enforced? Simply added to your taxes? For the record I think it's BS that I get fined for not giving my business to companies that I don't trust and are incentivized to screw me over. Signing up for Obamacare isn't signing up for health care, it's signing up insurance against grossly overpriced healthcare. Lets fix the problem, not play the insurance companies game.

<comment><USER3> I've heard from CPAs that have studied the law that Obamacare mostly seems to just be a series of taxes disguised as a healthcare law.

<comment><USER4> I would add it's a series of taxes directed at the self-employed. If you work for a large company or for the state/federal government you'll have insurance already. If you're unemployed, you'll qualify for a subsidy or medicare.

The self-employed are already paying double in medicaid and social security (I know employers pay half for the employed but it still discourages self- employment).

</comment></comment></comment><comment><USER5> _Technical problems due to scheduled maintenance is to blame_

'Scheduled maintenece' is either one hell of a euphamism or a most cynical Dark Pattern.

<comment><USER6> Yep. Why would anyone "schedule maintenance" on the day of the deadline?

</comment></comment><comment><USER7> For anyone wondering, the Obama administration has already built in a system for letting people who tried to sign up in the next couple days but didn't complete an application sign up without a fine in preparation for this. I'm sure it won't handle all cases and seems odd given how strict they said the deadline would be, but just for clarity of debate I wanted that out there.

<comment><USER8> Real Response: It's not so much a system as a "we're really not going to enforce this deadline for most people." It's not much of a system, it's more of a "we'll look the other way for some amount of time".

Snark Response: The Obama administration built a system for buying health insurance, and here we are... Presumably this system will work better?

<comment><USER9> " _a system for buying health insurance_ "

Except they didn't, as we usually view ecommerce sites. It sends (often erroneous) signup info to insurers, and it's between you and them to arrange payment.

</comment></comment></comment><comment><USER10> It looks like it was down for 8 hours total, 5 of which were scheduled.

<comment><USER11> Scheduled a major prolonged system outage the day before a major deadline? WTF?

 _Good morning, London. It is 6 am, the fifth of November 2019 and this is the voice of Fate. The new day brings good news and bright prospects from overseas, where negotiations with New China are moving in a positive direction. Last night 's scheduled demolition of two deteriorating landmarks went off without a hitch. Spokesman for the Interior ministry said both structures were severely damaged and judged to be a danger to the unsuspecting public. Plans for new landmarks are well underway._ \- Prothero, _V_for_Vendetta_ (Government commentary spinning unexpected destruction as "planned".)

</comment></comment><comment><USER12> This is normal for any systems of this type. The online tax returns system for HMRC in the UK does the same thing every year. People need do it earlier.

</comment><comment><USER13> If you wait till the last day, you are probably willing to pay the fine.

<comment><USER14> Fining people for failing to properly utilize a system that has never consistently worked is asinine. I imagine it won't be long after the first fines that they are challenged in court.

<comment><USER11> Fining people for failing to purchase a product is asinine. There's more precedent for requiring people to buy guns (and fining them if they don't; see Militia Act of 1792), but imagine the outrage if every able-bodied male 17-45 were required to buy an M16 and a case of ammo at their own cost (about $1000).

<comment><USER15> An M-16 costs _far_ more than $1,000, and is not available for purchase by the average citizen. Between the 1934 National Firearms Act, which prohibits the sale of fully automatic weapons to those who do not submit themselves to an extended (months' long) background check and pay an additional $200 tax stamp, and the 1986 National Firearms Act, which make all fully automatic firearms manufactured post-1986 non-transferrable to citizens means that the fair market value of an M16 is something closer to $15,000-$20,000, and that's for a used model that's at least 25 years old.

If those acts were repealed, I agree that the suggested MSRP for an M16 would be ~$1,000-$2,000.

<comment><USER9> I don't believe you're showing you get the point (while making a lot of good tangential points). I seem to remember that government's cost for buying a M4 is something like $600 in quantity, but I forget if that was Colt's price before they lost the contract to FN like they lost the M16 contract (the Army buys the former, the Marines, who are still riflemen, the latter with its much longer barrel necessary to achieve bare minimum performance with normal military ammo).

So presumably in an arming the militia regime, our cost would be lower than the 1-2K you postulate, probably even lower due to massive quantity. With of course subsidies to help the poor ^_^.

(Beginning modified, for bmelton not surprisingly does get the point.)

<comment><USER15> Oh, I got the point, but historically, it went the other way around. It was the government's duty to provide firearms to the militia for those that didn't have them themselves.

That said, your sub-point is humorous, but overlooks that if modeled after the ACA, subsidized M16s would be available for near free, while non-subsidized M16s would be ~$4,000-$5,000, if you're in too high a tax bracket.</comment></comment></comment></comment></comment></comment>


Proposed bill: Buy a house. Get a Visa? - <AUTHOR> http://online.wsj.com/article/SB10001424052970203752604576641421449460968.html

<comment><USER2> Saw awesome homes in Fremont , mountain view, new York and Virginia during my current visit, let the bill come would buy a home here.</comment>


Medoo 1.4 Released – The Lightest PHP Database Framework - <AUTHOR> https://medoo.in/ <comment><AUTHOR> The changes log about this release:

[https://github.com/catfan/Medoo/releases/tag/v1.4](https://github.com/catfan/Medoo/releases/tag/v1.4)

</comment><comment><USER2> I have been using this framework to a lot small projects. Great!</comment>


The Dark Side of Startups: 5 Corrosive Co-Founder Conflicts - <AUTHOR> http://onstartups.com/home/tabid/3339/bid/2148/The-Dark-Side-of-Startups-5-Corrosive-Co-Founder-Conflicts.aspx

<comment><USER2> I had the pit-bull conflict, where 1 of the the 5 would instigate a dog fight by building doubt about two of original founders. He would call up the other two guys only to talk about how the original founders didn't do it right. The other two guys became so weak and confused, GAWD, it was a nightmare relationship. The project died, the money drained, what a great lesson in regards to making sure the team works well together, has the same intention re the project, and feels fairly rewarded.

<comment><USER3> _"... the more founders you have, the worse disagreements you'll have. When there are just two or three founders, you know you have to resolve disputes immediately or perish. If there are seven or eight, disagreements can linger and harden into factions."_ \-- How to Start a Startup

</comment></comment><comment><AUTHOR> IMO, equal shares and consensus decision making go a long way in avoidance of a whole host of potentially fatal startup conflicts. And having a policy to openly discuss everything, which goes hand in hand with consensus decision making, creates a healthy forum to resolve conflicts before they blow up into unresolvable or annoying-to-resolve situations.

<comment><USER4> I agree with the transparency part, but I don't think the the "equal shares" concept is necessarily sound. It assumes that all founders are contributing equally which is not always the case.

What you are looking to do is make things equitable -- not equal.

<comment><USER3> Equal is optimal though. It's a matter of debate how much each is contributing but there's no debating whether 50% is half or not.</comment></comment></comment>


Anyone Get a YC S19 Videocall? - <AUTHOR> Did anyone get a YC video call? How did it go? - S2019 batch <comment><USER2> Yess I got one, they basically asked us simple questions like what are we building, what the available solution on the market, when we're going to launch (We're pre-launch), and etc. It is very short talk though.

<comment><USER3> What video call is this? Do everyone get a call?

</comment></comment><comment><USER4> Has anyone got invites as yet?</comment>


Squash your commits - <AUTHOR> https://github.com/blog/2141-squash-your-commits <comment><USER3> Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is _meaningful_ and will tell you a great deal about a project and its developers... I trust that. It's real and visceral and how software is actually made and you can learn from that or find things to explore in that jungle. Projects with multiple developers that yet have straight line commit histories and super tidy commits are aberrations and full of little lies...

Kudos to GitHub for providing this feature that a lot of people have asked for. I obviously don't plan to use it, but I appreciate that it's an option for those people that like their small, harmless lies. ;)

<comment><USER4> _isn 't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that._

      Here is a (made up), but generally realistic git log

      git log | grep -i WIP

      mon 5pm - WIP, going to work on this from home
      tue 4:45pm - WIP, going to work on this from home
      wed 2:30pm - WIP, meeting
      wed 5pm - <USER2>
      thu Noon - WIP, working from the cafe on my laptop
      fri 5pm - WIP, working from home
      sat 3pm - WIP, heading home sick for the day

Does it really matter to anyone, and count as anything but noise to know that I committed my work in to the repository just so that I could work on it from a different computer. I can't imagine how low the signal to noise ratio would be if every person on the team did this.

<comment><USER5> I think this is a strawman - I don't think anyone is suggesting publishing WIP commits.

<comment><USER6> Isn't that _exactly_ what the original commenter is suggesting?

> no rebases, no squashes, sometimes not even fast-forwards

<comment><USER5> I think the implication is rebases or squashes of _already published_ work.

<comment><USER3> Thanks, that was indeed the primary implication.

That said, I've been happy to debate the larger implications that there are UI/UX tweaks/story-telling that could make even the work-in-progress non yet published stuff more appealing to publish without needed to mutate it from its as-developed states... But yes, I was mostly speaking to published commits.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is a bad idea masquerading as a good idea. Before making a pull request (or doing any sort of merge), you should rebase against upstream master (or whatever you're going to push to). However, keeping distinct atomic commits that change one and only one small thing, when possible, is much preferable if bisect or blame is used. If you have broken or poorly written commits, use fixup, reword, squash, etc. in rebase -i.

Using fast-forward (and possibly only allowing fast-forward) is a good idea. Squashing entire pull requests that may change multiple things into a single commit is a very bad idea.

<comment><USER8> > Before making a pull request (or doing any sort of merge), you should rebase > against upstream master (or whatever you're going to push to)

See, and maybe this is because I'm just dumb or something, but I have _never_ gotten rebasing to work for me. Ever. Every single time I do it I read at east 3 articles about it so I don't screw something up, I attempt to do it and ultimately I lose a bunch of work.

I just don't get it. I can write web, mobile and desktop apps and I like to think I'm pretty good at it. But I'm one _of those people_ who constantly have commits of merges in their code because for whatever reason I just can't get my head around making rebasing work correctly.

Am I the only one? Sorry for the derail but it's bothering me that I've never gotten this to work correctly and I feel otherwise normally smart. ¯\\_(ツ)_/¯

<comment><USER9> I know that I probably swear in church since git is the current de facto standard for version control but this shows that gits usability is way too low. Why do I have to invest so much time to understand the inner workings of a tool that should just help me collaborate with my coworkers? I've given up on understanding git and use gitflow and the built in tools in Intellij Idea for all my branching/merging/committing needs.

<comment><USER10> While I like the git flow model, I find the git flow plugin really useless.

You lose so much of the power that makes git such an awesome tool.

Same with every single front end to git I've ever tried, free or purchased. I always come back to the CLI because it's so much more powerful.

The IntellJ merge tool is pretty nice though.

</comment></comment></comment></comment><comment><USER11> I mentioned this in a tweet[0] but we have a quasi-tradition of shipping on April 1st:

* [https://github.com/blog/1815-l-is-for-labels](https://github.com/blog/1815-l-is-for-labels)

* [https://github.com/blog/1451-branch-and-tag-labels-for-commi...](https://github.com/blog/1451-branch-and-tag-labels-for-commit-pages)

* [https://github.com/blog/626-announcing-svn-support](https://github.com/blog/626-announcing-svn-support)

[0]: [https://twitter.com/gjtorikian/status/715972348860633088](https://twitter.com/gjtorikian/status/715972348860633088)

<comment><USER12> The first time we announced svn support, it WAS a joke: [https://github.com/blog/31-back-to- subversion](https://github.com/blog/31-back-to-subversion)

</comment></comment><comment><USER13> This is a presentation issue masquerading as a data issue. If somebody suggested deleting data because a report was ugly, they'd be laughed out of the room.

Give us tools to mark commits as unimportant or group them together as a meta- commit object for history purposes.

<comment><USER14> > If somebody suggested deleting data because a report was ugly, they'd be > laughed out of the room.

If somebody suggested keeping data that showed every step of a person writing a report, they'd be laughed out of the room.

It's gray area that varies significantly by feature complexity and team dynamic. I find it frustrating when someone merges a branch with 1 real commit and 3 more one-line commits or trivial fixes that should have been in the first.

<comment><USER15> It's equally frustrating to have cs commits fixed up with a meaningful commit, making the diff of the meaningful commit ugly.

</comment></comment></comment><comment><USER16> I hate squashing branches. There's a lot of value in commit messages; they're educational and are a form of documentation. It's on the developer to squash the "oops" commits, during a rebase, rewriting the commit message so it has some value when going back in time to look at changes.

I'd love to see a commit linter, that points at commits with text like "oops" and "fix my derp" to suggest possible commits to squash.

Git history shouldn't resemble a hot mess, but the evolution of code should be pretty granular. I'd take the hot mess over full squashing, though.

<comment><USER17> Commits to squash can start with [squash] and when you rebase they are automatically squashed.

</comment></comment><comment><USER18> Perhaps I'm greedy, but I'd like also an additional option to rebase without squashing ...

Also, it's not clear if it is possible to disable the merge button completely. I prefer to use the command line to rebase and fix the details in the commits, but the big green "merge" button is always too tempting and it's easy to press it by mistake.

<comment><USER19> This is a huge issue for me both with GitHub and Atlassian Stash.

On both you even _cannot see_ when the branch was started, and you can merge fine as long as there were no merge issues. Then you run gitk and it looks like a spaghetti-horror, with trivial branches being started 200 commits ago.

I don't necessarily need a "rebase&merge" button but at least info about the shared ancestor with master.

</comment></comment><comment><USER20> This is a feature I've wanted for such a long time. While it's perfectly feasible to do through the command line, I've always found myself having to force push to update the history on github's side of things.

I typically did it through git rebase -i HEAD~N, so maybe someone here on HN knows of a better way to squash a commit whenever you're updating remote history. Albeit, it seems that updating remote history with a squashed commit isn't entirely attractive behavior and that's why I was forced to force push.

<comment><USER21> Two things you can do differently, if you feel this would be appropriate.

Instead of git rebase -i HEAD~N, I typically use git reset --soft HEAD~N followed by git commit.

Instead of git push --force, use git push --force-with-lease. This only updates the remote if the remote's current state is what you expect. For example, it will fail if someone else has pushed to the same branch in the meantime.

</comment></comment><comment><USER22> Nice to see Github catching up to Gitlab[1]

[1]: [http://feedback.gitlab.com/forums/176466-deprecated- feedback...](http://feedback.gitlab.com/forums/176466-deprecated-feedback- forum/suggestions/4289653-rebase-merge-requests-in-the-web-ui)

<comment><USER23> For sure! Good thing we have some great stuff in the pipeline [https://about.gitlab.com/direction/](https://about.gitlab.com/direction/) :)

</comment></comment><comment><USER24> Oh god no. I made the mistake of moving a team to squashed commits once. The lack of individual commits poses large problems down the line. 2 nonstarters come to mind:

1: Completely ruin your ability to git bisect any bug injected in your branch. Instead of getting a 10 line commit, bisect will point you to hundreds or thousands of lines instead.

2: All code will blame to a single person. Code with 6 people on a large branch? Want to git blame the code to see who wrote the function that is weird looking so you can ask questions? Too bad.

Do not squash branches on teams. One of the biggest mistakes of my professional career.

<comment><USER25> This is for a "pull request", namely an individual logical change. Your two points don't apply. If you're dealing with whole branches with multiple developers, stick with merging, but this isn't that.

</comment></comment><comment><USER26> This is awfull because it destroys information.

A feature branch needs cleaning up before publishing. These bug and typo fixes needs to be squashed in the branch, but the history should preserve a sequence of commits corresponding to atomic changes because it tells a story.

A commit should be small enough to make it easy to check if the change is correct. It should be self contained so that it can be moved arround, cherry picked, etc.

This is why the local commit history should be considered as a draft of the story, and the one published should be the official one aimed to be easily readable, verifiable and manipulable.

</comment><comment><USER27> Any plans to allow for squashing but with a merge instead of a fast-forward or fast-forwards without squashing?

CI will still run against the hypothetical merge commit, no? I wonder if there are edge cases where merge vs squash+fast-forward would result in different conflict resolutions and different trees, so master could end up with a tree that didn't have tests run against it.

<comment><USER28> > master could end up with a tree that didn't have tests run against it

Isn't that already the norm? I.e., most projects run CI on an unmerged PR, then merge to master, then run CI on master to see if the merged tree is actually good. Are there projects which test a PR's post-merge tree before updating master? That would be nice, but I don't know of any tools which support that workflow, and it wouldn't scale forever since it would involve a serial merge queue.

<comment><USER29> Travis CI for example and I'd imagine most CI servers run tests on the `MERGE_HEAD` of the PR which like lotyrin said is the hypothetical merge commit. If a PR is opened from latest master, CI runs on `MERGE_HEAD` which is the same with the merge commit after the PR is merged. But if something was pushed to master after the feature branch was branched off then it's not the same commit. That's why it's recommended to run CI after merging again. But by default tests are not run on the PR HEAD which is the tip of the feature branch.

</comment></comment></comment><comment><USER30> I'm confused. When I don't want to see the details of the topic branches, I run 'git log --first-parent'.

Why not make it easier to see what I want to see, but then let me drill down and see more, instead of removing the details all together?

</comment><comment><USER31> No, don't squash your commits. This is stupid advice that comes back over and over.

Squashing commits is a useless thing that has absolutely no benefit. It's dumb. It really makes no sense. It has very clear negatives.

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

</comment><comment><USER32> Call me naive, but wouldn't this problem be best solved by requiring that commits represent meaningful and working increments of work?

I use 'git add -p' judiciously and only commit when having reached a point where something can be usefully said to be in some way "done". Sure, it's not perfect, and occasionally I end up having to do some cleanup of miscellaneous printf statements, debug values or typoes in subsequent commits, but this is something that should really be avoided if possible.

<comment><USER33> Waiting until you have something useful has other drawbacks. For example, it might take many hours or days to get to a 'useful' and 'done' state - I don't want to go hours or days without saving my work in a manner that is easy to retrieve if something goes wrong.

Besides the obvious 'hard drive failure' or 'laptop stolen' situations, there are also more frequent situations where 'oh shit, I went down a totally wrong path there - let me back up a bit and try that again.' Git commits are little save points that let me do small experimentation and go back if I need to.

<comment><USER32> Very good points. I guess I've just been too lazy to learn advanced rebasing / commit aggregation. Maybe I should, so I can more effectively take advantage of the upside while not polluting my commit history with intermediate crap.

</comment></comment></comment><comment><USER34> I'm waiting for the code review tool that takes a massive squashed PR and cuts it up into a series of clean, atomic commits that can be reviewed individually.

<comment><USER35> I believe Phabricator supports this workflow. Create a revision for a code change - as more commits are made, update the revision with those changes. Users can see what changes were made between commits and hold discussions on them. When it's ready, landing can (optionally) squash the diffs into a single commit upstream. The main history will be linear and more-complete changes, while detail about the development of the change is retained in Phabricator revision.

[https://phacility.com/phabricator/differential/](https://phacility.com/phabricator/differential/)

</comment></comment><comment><USER36> Yeah, this is dumb. Being able to effectively bisect large projects depends on having smaller commits. If your commits are all huge, your bisect will hit some 500 line patch that does 5 different things -- it'll easily quadruple the debugging time. Not to mention that having small self-contained commits is a _good thing_.

</comment><comment><USER37> This, as rebase, is a great idea for people who would rather use SVN instead, but have to use git for some reason or another.

I mean, if you want your history simplified into a linear squashed series of commits, why the hell do you use VCS which models a history as acyclic directional graph in the first place?

</comment><comment><USER38> Maybe I'm missing something, but I've never understood the point of cleaning up commit history. The only time I ever look at commit history past a few days is if I want to know when something broke (in which case I WANT every part of the history, even the messy bits), or if I'm trying to refresh my memory of what I've done for the year (for performance reviews or whatever) in which case I guess it's marginally useful, but it's pretty easy to skim over "fix build" and such.

</comment><comment><USER39> As this thread approaches 300 posts I'm wondering when we're going to get out of this Git Tarpit we've somehow got ourselves into?

To be charitable: Git seems to be a good tool designed for Problem A, being widely used for Problems B,C,D for which it is a fairly poor choice.

I _think_ we got here through some mix of "but it's really fast!"; "I can do _anything_!!"; "But Linus says its great!"; "I don't need to pay for a beefy server any more!"; "New _must_ be good, right?".

In any event, how do we get out the ditch and back to work making software vs. trying to reason about the unreasonable? I personally, for the kind of projects I'm involved with (small teams, all paid by the same piper, with aligned clear goals and competent coders), had perfectly satisfactory revision control systems since around 2000 (except when required by employer to use Clearcase..). It would be nice to get back to that future.

</comment><comment><USER40> Annoying: you can't turn off both. If your project has a workflow where the webui merge should not be used (e.g. using signed merges) there is still no way to achieve that.

</comment><comment><USER41> Wow, loved this.

I contributed a little to JUnit and they ask you to squash your commits before making a pull, it took some time to do it, it's so confusing/wierd using regular GIT.

</comment><comment><USER42> Awesome! Phabricator got me addicted to the clean history of squashing commits and the logical changes staying together in source control (as opposed to grouping in a PR).

</comment><comment><USER43> It seems to me that the scope of this article is pretty narrow (in a good let's avoid a flame war way). And it describes one of the few scenarios where I think squashes are beneficial.

But then the conclusion doesn't quite add up. if I want to remove all the merge mess from a PR don't I actually want to rebase the PR, not merely squash the history? Or dos I miss the point he was making?

</comment><comment><USER44> This is such a nice feature. Thank you for working on it. Keeping history clean is important, especially in enterprise solution where you have to keep support multiple releases. You want to select certain commits/features in one version. With merge/squash, you would get a cleaner history, and it is easy to pick commits you want.

</comment><comment><USER45> I believe there should be more open communication and a record the public can fall back on while these developers make their improvements. Something in their face. Too many times did I track back and see unprofessional comments being made and things being done that seemed downright suspicious.

if it were up to me it would be alot harder to get a developers license and you would have to meet regulatory standards and have degrees to uphold your professionalism while acting as your own developer it seems to me that alot of developers have taken things into their own hands and are trying to make a quick buck any way they can get it. don't be surprised if you tell your mother or father or sibling to look at what licenses they have agreed to on their phones and they find alot of outdated unassigned licenses to back up their privacy. it seems to be an epidemic and how are we going to stop it?

</comment><comment><USER46> This obsession with "clean" history seems to me nothing short of insanity. Source control has one job: to record the history of code in order to be aid in figuring out what happened when things go wrong. If everything always went well, we'd just have great merge tools and throw away the history.

I can understand a desire to filter out stages of a project by different levels of review (I just ran the build and tests passed so I committed vs a bunch of people reviewed it so I merged), but that people solve that by deleting or rewriting history to be something different from what actually happened is just nuts.

Is it just that git makes it easier to change history than to add metadata for filtering? Why have we not seen presentation tools to solve this problem rather than what seems like a ubiquitous readiness to alter and throw away the messy but accurate facts about what happened?

<comment><USER47> Because the lack of squashing actually makes finding bugs harder. Which checkin with the status "change i to l" or "whoops, typo" was the bug in?

It's a lot easier when an entire changeset has a single checkin into master, because then when you're doing your bisection there are a far few changes to bisect.

</comment></comment><comment><USER48> I could see this replacing the git workflow of creating a temporary branch that's used just for merging pre-master.

</comment><comment><USER49> The key principle is that the software should always correctly work at any point in the chain of commits, so you must squash commits that are "oops, fix X in previous commit".

Once that is satisfied, commits should be as small as possible, so that information about the grouping of changes is preserved.

<comment><USER50> This advice seems very sensible. Thanks for adding some valuable ideas to the discussion. I'm now reading the git documentation on re-writing history:

[https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History](https://git- scm.com/book/en/v2/Git-Tools-Rewriting-History)

</comment></comment><comment><USER34> After completing a feature (or part of one) I often "squash" manually by performing a mixed reset from the tip of the in-development branch back to a good parent commit.

This leaves all of the feature's changes in your working copy, which you can then stage by line/hunk and individually commit in clean, atomic pieces with the benefit of already having written the final code.

This removes the in-progress commits like a Squash, but pieces of code can still be brought in as individual easy-to-review commits. And it's potentially easier to understand / perform manually than rewriting history via a git command that would do the same thing.

</comment><comment><USER51> This is great! But what about fixups? I often prefer a fixup to a squash when the commit in question was a WIP or something, and I don't have any desire to preserve the message in the final commit.

</comment><comment><USER15> This is wrong at so many levels. Of course we don't care about "progress" or "woops I fucked up" commits, but people also do commits for things like coding style, and these commits should be keep separated from the others, and DO NOT warrant a separate PR. If it is about changing all tabs to space in a file, for instance, different PRs will be hard to work with, because of conflicts. Also, people who write WIP commits should learn how to squash them themselves, and give them a meaningful commit message.

</comment><comment><USER52> Usually when squashing branches locally, all the changes are set to myself as the author, effectively losing history of who did what in the feature branch. How does Github handle this?

Additionally, the lack of the commit history for that branch often caused merged conflicts when merging the same branch again (if it had additional new fixes, for example). That's why I switched to using git merge --no-ff.

If it were very easy to do, I would definitely do a git squash, as it keeps history very clean. I just don't want to have the problems listed above.

</comment><comment><USER53> I think squashing commits makes sense if you're working in a big team and/or on a complex/large project - The main advantage of it is that it speeds up the QA process because it cleans up all the back-and-forth (exploratory) changes that tend to happen during development.

If you squash properly, each commit will represent a small standalone feature.

It does reduce your commit count though :(

</comment><comment><USER54> Squashing is not an alternative to merge workflow. It's what you do to clean up _before_ you integrate your work (whether by rebase or merge). You've just made seven changes, which should just be three: git rebase -i HEAD~7, squash away. Okay, now you have three. rebase them on top of new work in the upstream branch, or merge? Separate question.

</comment><comment><USER55> This is great news for us as we prefer this flow. However, we actually mostly merge via our custom tool which uses GitHub's API. I can't find anything in the documentation about whether these options apply to API merges or if there's any query params that can achieve that behavior from the API. Anyone know anything about this?

</comment><comment><USER56> I personally like this and it fits well with my team's workflow (though I am a bit concerned it will prevent engineers from learning to do these things with git). There are pros and cons for sure but I think if you are losing a lot of resolution by squashing then the scope of your pull requests might be too big in the first place.

</comment><comment><USER57> The option to avoid merge commits when merging pull requests misses the point, but apparently many users demanded it for some reason, so Github implemented it.

Here's how merge commits, rebasing and isolated small commits work:

You branch your topic off master and make many commits while working on it. This is all local.

Once you're ready to publish for review/integration, you squash fixup and backup commits into a coherent patch set, where each and every revision builds and works. This is where you can rebase and squash for good reason. Now you can push to Github.

If you, like Phrabricator, create a single big commit with all changes lumped together, then it's impossible to bisect and follow the thought process behind changes. Try to git-bisect linux.git vs a repo that's been managed with Phabricator and its mega commits.

With small commits that each make one coherent change, you can easily include relevant explanations in the commit message, which is much harder to achieve with a single mega commit. Further, it's very simple to follow along the development process of changes with separate commits. If you have one big diff, it's hard to understand the changes of a branch, whereas reviewing small commits with an explanation in the message and the overall reduction in diff size makes it much, much easier to understand for reviewers.

With separate small commits you review each step and finally arrive at the complete feature implementation at the end. For someone who has to review code they didn't write this saves a huge amount of valuable reviewer time for actual reviewing than trying to reverse engineer the steps taken in a big diff.

Moreover, with multiple commits, you can easily approve of some of the commits, while requesting improvements for others.

Gerrit implements this well and the process is what linux and git and other projects use when reviewing big patch sets. Set is the important word.

Finally, why do you want merge commits? Unless you always make a single mega commit ala Phabricator or the new Github feature, having merge commits provides a very practical way to see that a set of commits landed via foo- branch-X. If you've ever viewed a git log graph, that's the interesting integration points, which you will lose if you omit merge commits. In a merge commit you can also include extra stuff as part of the merge commit itself, so it's not just useless metadata.

</comment><comment><USER58> Do any VCSs have a notion of a commit of commits? If you could group a series of sequential commits into one commit on trunk it seems like you could have the best of both worlds: an overarching commit for your change and a series of how the sausage got made.

<comment><USER14> Sure, a merge commit.

        git checkout master
        git merge --no-ff feature-branch

</comment></comment><comment><USER59> Equally, [https://github.com/git-land/git-land](https://github.com/git- land/git-land)

"This is a git extension that merges a pull request or topic branch via rebasing so as to avoid a merge commit."

</comment><comment><USER60> Rarely do conversations around these parts get as heated as they do when git process comes up. As I read through these comments, only one thing surfaces: everybody organizes their shit differently. If you're here trying to sell your process, why?

</comment><comment><USER61> A bit OT but a feature I would love to see in git is to be able to see which branch a commit came from. Especially for shortlived branches which we prune periodically on the server (git branch -r --contains won't work as a result)

</comment><comment><USER62> This is great, but I was really hoping for a fast-forward-only merge button...

<comment><USER63> I think you can fake this by enabling "Require CI" and not selecting any required CI branches.

</comment></comment><comment><USER64> This always reminds me of stackenblochen [https://youtu.be/Qo_2ReMNzhU](https://youtu.be/Qo_2ReMNzhU)

</comment><comment><USER45> I can't believe some of the comments I have seen made back and forth. let's shoot for a professionalism to supercede all others

</comment><comment><USER65> An unique thing: [http://i.imgur.com/ztUufvf.jpg](http://i.imgur.com/ztUufvf.jpg)

</comment><comment><USER66> Fantastic.

Regarding non-merge workflows: For me the question is:

should git history reflect a literal record of keystrokes or should it reflect intent?

I strongly believe in the latter.

</comment><comment><USER45> no reason why developers should not be reliable for their work. if you ask me there should be a process to handing out open licenses and from what I have seen apache gives any one the right to do what they want. I would love to see stricter laws when it comes to third parties and open source licensing, including the chatter back and forth.

</comment><comment><USER67> Can't wait to see this feature replicated poorly in about 6 months in Atlassian Stash (Bitbucket)!

<comment><USER68> Actually Bitbucket Server (née Stash) already supports squashing and a variety of other pull request merge strategies. They're just configured[0] per repository, project or globally rather than an explicit option at merge time.

[0]: [https://confluence.atlassian.com/bitbucketserver/bitbucket-s...](https://confluence.atlassian.com/bitbucketserver/bitbucket- server-config-properties-776640155.html#BitbucketServerconfigproperties- Pullrequests)

</comment></comment><comment><USER69> If everyone on your team actually knows how to use git, much better to let them rebase their commits and mark out a series of clean, atomic commits which introduce the feature you're reviewing. If you have people who are incompetent at using git on your team, this feature will help protect your history from them.

<comment><USER70> > incompetent at using git

This unfairly places the blame for Git's utterly shitty UX on the part of the users. When you have thousands of users who struggle to use a tool correctly, it's the tool's fault, not theirs.

I've been using Git for years, work professionally full time on an open source project that lives on GitHub, maintain several open source projects with a number of committers and generally live and breath Git and GitHub all day.

I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it.

<comment><USER71> > I still fucking hate rebasing and get tripped up by it on the few times I > end up having to deal with it.

When I had no understanding of what was going on, I didn't like it either. Now that I use it frequently, I understand it better, so I don't hate it anymore.

I like running `git rebase <main-branch>`, where <main-branch> is typically master, in my-new-thing branch because it lets me deal with any conflicts from upstream one by one.

I also like running `git rebase -i` in my-new-thing when I have a bunch of commits with redundant messages that I want squashed into a single commit before I push the changes. Basically anything that requires messing around with a range of commits is a good use case for `git rebase -i`.

Why do you hate it so much? There's really not much going on that you should have to hate. To me it's like a bunch of small, compartmentalized merges.

<comment><USER72> Genuinely curious, why the love for the `git rebase -i`? I find it much easier and more intuitive to squash a set of linear commits on a branch using `git reset --soft HEAD~n` where n is the number of commits to go back and "undo". Then make one more commit and you're off to the races. Note: this is not useful if force push is disabled and you've already pushed some of the commits to the remote (feature) branch.

<comment><USER73> In addition to bpicolo's point below, things quickly break down if your commits have file removal or renames. I've gotten bitten more than once and now always resort to git rebase [-i] to avoid this.

</comment></comment></comment></comment></comment><comment> mck- Added benefit of this would be that it is easier to git revert a merge from cli

</comment><comment><USER74> Wait, this isn't new.

</comment><comment><USER75> Unsure if April Fool's joke...

<comment><USER76> Would be the worst April Fools joke ever. Even above "drop mic" by Google.</comment></comment>