I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how

I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. I actually agree. I advocated for DVCS-based workflows for a long time, but I think it speaks volumes that I "got" Darcs within about 20 minutes of first seeing it and playing with it, but I know for a fact that, somewhere in the Freenode archives, you can find me saying "The frak is Mercurial? The frak is Git? The frak is this?" as I tried to grok what on Earth they were doing--and this after having taught myself tla! That said, just because something is intuitive doesn't necessarily mean that something is best engineering discipline. I want a Darcs-like workflow to be the dominant one specifically because it's intuitive, but I'm very open to the fact that it might be a really, really crappy way to build a sane (forget performant) large code base. Or it may be exactly what we've always wanted. The simple fact is that I have no idea. This industry, for all the "science" in CS, has got to be the least results-based discipline I'm personally aware of. Pijul will at least permit anecdotal tests of how well patch-based systems scale as a workflow if it takes off, but I'm not holding my breath on someone doing a genuine A/B productivity/trade-off study.