I love git lens for vscode.
[todo: insert screenshot]
but actually managing the commit message text revealed by git lens via git rebase is a little crazy making
it is a nice way to really make sure you maintain very clear history/state of your code
I love git lens for vscode.
[todo: insert screenshot]
but actually managing the commit message text revealed by git lens via git rebase is a little crazy making
it is a nice way to really make sure you maintain very clear history/state of your code
| // https://stackoverflow.com/questions/43004657/modify-the-url-of-a-new-request-object-in-es6 | |
| // used to monkey patch a `fetch` call inside some javascript framework. | |
| const serverFnFetch: typeof fetch = function (input, init) { | |
| const isRequest = input instanceof Request; | |
| const currentUrlObj = new URL( | |
| isRequest ? input.url : input, | |
| location.href, | |
| ); | |
| const currentUrlWithoutOrigin = currentUrlObj |
| import React from 'react'; | |
| import { useCheckoutSessionId } from '../useCheckoutSessionId'; | |
| type ComponentThatRequiresCheckoutSessionId<TProps> = ( | |
| yourBaseProps: TProps, | |
| ) => JSX.Element | null; | |
| /** Patches return type */ | |
| type RemoveProp< |
| type asdf = HTMLElement; | |
| const validateElement = < | |
| // eslint-disable-next-line @typescript-eslint/ban-types | |
| TInstanceType extends Element, | |
| >( | |
| node: Element | null, | |
| { | |
| nodeNickname, | |
| tagName, |
in response to https://www.patreon.com/posts/worst-place-to-74324982
ci/cd pipeline stuff is not AS shareable as git hooks. Every ci provider has their own .yml flavor... But even a pre-commit hook can be too late in the process in some situations. I think it'd be really cool to:
Let's imagine you produce an sdk, an npm package named @crazy/foo,
You like monorepos, but you have example apps in separate repos, and those example apps can't be brought into the monorepo for some reason.
You want those example apps to also function as automated tests, and, you want them to be updated in lockstep with @crazy/foo sdk changes.
Devin finds monorepos are always better, and believes it's best to work from first principles to solve any problem you have, in a way that does not involve multiple git repos.
| declare module "redux" { | |
| /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */ | |
| function compose( | |
| /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */ | |
| a: never, | |
| /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */ | |
| b: never, | |
| /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */ | |
| c: never, | |
| /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */ |
I would DIE for a gui
here's the thing
I create lots of well-sequenced, very intentional commits. They are small and repeatable, so it makes it easy to handle rebase conflicts. Just read commit message, see original diff, and 80-90% of the time I believe anyone should be able to see what the original commit was doing and resolve conflict such that same thing is being accomplished on new base. Almost each commit could be one PR, but maybe sometimes it's better to group few commits into one PR.
I'd like to create a PR stack so that it's easy for others to review my changes, but, I don't want to mess around with git branches locally at all. I'm already a surgeon with rebase.
Ideally, I have a gui tool.
Converted to usable .json files: https://github.com/devinrhode2/tsconfigs-by-strictness
| [alias] | |
| add-archive = "!runit() { REFS_BRANCH=`git branch -a --contains $1 | xargs` && \ | |
| NEW_REF=`echo refs/archive/$(date '+%Y-%m-%d')/$(git config user.name)/$REFS_BRANCH/$(date '+%s')` && \ | |
| git update-ref $NEW_REF $1 && \ | |
| echo consider deleting $REFS_BRANCH && \ | |
| echo attempting to backup archives && \ | |
| git push origin refs/archive/*:refs/archive/* && \ | |
| echo Here is your remote commit ref url && \ | |
| echo https://github.com/org/repo/commit/$1; }; runit" |