See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope>
is optional
sudo vi /etc/postfix/main.cf
Branch A has commits (X,Y) that also need to be in Branch B. The cherry-pick operations should be done in the same chronological order that the commits appear in Branch A.
cherry-pick
does support a range of commits, but if you have merge commits in that range, it gets really complicated
git checkout branch-B
git cherry-pick X
git cherry-pick Y
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
gatsby-config.js
first.require('ts-node').register()
which registers a TypeScript evaluator that will be used when Gatsby
reads all other API Javascript files. In other words, we only need to do
this once in our entire codebase and not in other Gatsby files like
gatsby-node.js
.gatsby-config.js
re-exports all the exported variables available
in gatsby-config.ts
.I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
const sanityClient = require('@sanity/client'); | |
const crypto = require('crypto'); | |
const { | |
SANITY_API_TOKEN, | |
SANITY_PROJECT_ID, | |
SANITY_DATASET, | |
SHOPIFY_SECRET | |
} = process.env; |
Example repo for 11ty/eleventy#2248.
This gist was created by @pspeter3!
but the reality is that most Haligonians will know you're a "come from away"
notes: Halifax is best in the early fall. The smell of the ocean with the smell of freshly falling leaves is... unique to this place and makes me smile everytime that i think of it.
Day 1