You can also tell git that the .git dir is completely separated from the working dir:
alias dogit='GIT_WORK_TREE=/path/to/src/dir GIT_DIR=/path/to/dotgit/dir git'
dogit pull remote treeish
---
I set this up as a "poor man's version control" on a large client's server back in 2016-ish. I was lost for words when last year I saw my colleagues still using Ctrl-R to rerun that alias line.
Yeah, nowadays most of the sites are suffering from div-ititis that has no semantics, massive blackholes of JavaScript that have to be loaded and processed before you can even see plain text, and CSS class names that are randomly hashed with each deployment in the name of modularity.
General accessibility be damned.
<noscript> fallback messages be damned. (Except when snitching on your page views to Google Analytics, that's too important to be neglected! I wonder if GA has any default marker to let their customers distinguish these views from normal ones, or if that's still left to each customer to implement manually.)
UI customizations in the form of browser extensions and styles be damned.
Generally, it should be noted that an <a> tag is only appropriate if it makes sense to right-click this element and get options to "open in new tab" or "add to bookmarks". All the stupid "buttons" implemented as <a href="#"> + e.preventDefault() need to die.
I think what they mean is this: if you're dissatisfied with invoice PDFs generated and sent by Stripe, it's fairly common to disable the sending and use an integration [0] to generate/send them out instead. And then if you cancel that integration, oops, your customers no longer get their invoices.
This is like asking "vim or emacs". You'll never change anyone's mind on the matter, but you'll get the same old arguments from ~ten years ago [0] about how this is both "very simple†" and "pointless mental overhead" at the same time.
† (if you follow these rules I memorized to show off how smart I am).
That reminds me of a vendor who wraps SAP Business One in their own webservice. This webservice has two business methods.
The first one, ExecuteXML, takes an <XmlBody> representing a regular SAP B1 XML request and passes it on to one of the real SAP services. We have to find our own XSDs for the inner part, because they sure as hell don't have those.
The second one is ExecuteSQL. It lets us run raw SQL against the SAP database. It doesn't have any support for prepared parameters. What it does have is a blacklist to prevent DDL and other funny business, such as semicolons. This blacklist runs on the raw string you send, and doesn't understand any escape characters. To send a string containing a literal semicolon, I had to turn it into CONVERT(VARCHAR(MAX), 0x...).
> Can I possibly even start the discussion at why the hell these things are being named in this way?
This reminds me a lot of Perl with its creative naming for things, e.g. promises giving you a `Vow` object that you can `keep()` or `break()`. Or how you `bless` an associative array into becoming an object of a certain class.
On the one hand, it is good to have precise and specific terms without reaching for a thesaurus or overloading the same term (e.g. the many meanings of `static` in C).
On the other hand, if every framework and language invents its own terms for everything under the sun, that will not help polyglots or newcomers.
(On the third hand, we have foreigners trying to spot a difference between a "promise" and a "vow".)
Promises are my favourite example of this, because just between C++, C#, JavaScript, and Perl, I can find three-and-a-half different taxonomies for the same functionality.
[0]: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eInv...