- Call 1-800-829-1040
- Press 1 for English (or other language as desired)
- Press 2 for personal tax
- Press 1 for form / tax history
- Press 3 for other
- Press 2 for other
- Ignore 2 SSN prompts till you get secret other menu
- Press 2 for personal tax
- Press 3 for other
- Wait for agent!
# ruby's git repo investigation zsh one-liner-ish thingy | |
# (a starting point for investigating anomalous contributions in git repositories) | |
echo "$(find . -type f ! -size 0 ! -path './.git*' -exec grep -IL . "{}" \;)" | \ | |
sed -e "s/^\.\///g" | \ | |
while read line; \ | |
do \ | |
echo ">>>>>>>>$line"; \ | |
echo "$(git log --follow --find-renames=40% --pretty=format:"%ad%x0A%h%x0A%an%x20<%ae>%x0A%s" -- "$line" | head -n 4)"; \ | |
commitdates="$(git log --follow --find-renames=40% --pretty=format:"%ae" -- "$line" | head -n 1 | xargs -I {} git log --author={} --pretty=format:"%ad")"; \ |
I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.
I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:
Reference https://stackoverflow.com/a/34407620/13287790
$ printf %s 'encode this'|jq -sRr @uri
encode%20this
$ jq -rn --arg x 'encode this' '$x|@uri'
encode%20this
-r (--raw-output) outputs the raw contents of strings instead of JSON string literals. -n (--null-input) doesn't read input from STDIN.
-R (--raw-input) treats input lines as strings instead of parsing them as JSON, and -sR (--slurp --raw-input) reads the input into a single string. You can replace -sRr with -Rr if your input only contains a single line, or if you don't want to replace linefeeds with %0A:
The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the
Fish is a smart and user-friendly command line (like bash or zsh). This is how you can instal Fish on MacOS and make your default shell.
Note that you need the https://brew.sh/ package manager installed on your machine.
brew install fish
oc get pod -o jsonpath='{range .items[*]}{"SPEC: \n LIMITS : "}{.spec.containers[*].resources.limits}{"\n REQUESTS: "}{.spec.containers[*].resources.requests}{"\n"}{end}'
oc get pod -o jsonpath='{range .items[*]}{"NAME: "}{.metadata.name}{"\nSPEC: \n LIMITS : "}{.spec.containers[*].resources.limits}{"\n REQUESTS: "}{.spec.containers[*].resources.requests}{"\n\n"}{end}'