One Paragraph of project description goes here
Describe in detail functions of the code.
#!/usr/bin/env bash | |
# | |
# Script name -- purpose | |
# | |
# Author: | |
set -o errexit # abort on nonzero exitstatus | |
set -o nounset # abort on unbound variable | |
# |
# ~/.gitconfig | |
[branch] | |
autosetupmerge = true | |
[push] | |
default = current | |
[core] | |
excludesfile = .gitignore |
# Adapted from [codedot/ics2tc.awk](https://gist.github.com/codedot/1cce55b4fd354b470becb8ce341b6598) | |
# Parse ics to pipe seperated values for further processing | |
# pass in vars (-v from=remove entries before this date) (-v source=add string so i know source from multiple ics's) | |
function parse(dt) { | |
Y = substr(dt, 1, 4); | |
M = substr(dt, 5, 2); | |
D = substr(dt, 7, 2); | |
h = substr(dt, 10, 2); | |
m = substr(dt, 12, 2); |
// | |
// RandomNames.swift | |
// | |
// Created by Lütfi Tekin on 27.12.2017. | |
// | |
class RandomNickNames{ | |
static let adjectiveList = ["aback","abaft","abandoned","abashed","aberrant","abhorrent","abiding","abject","ablaze","able","abnormal","aboard","aboriginal","abortive","abounding","abrasive","abrupt","absent","absorbed","absorbing","abstracted","absurd","abundant","abusive","acceptable","accessible","accidental","accurate","acid","acidic","acoustic","acrid","actually","ad","hoc","adamant","adaptable","addicted","adhesive","adjoining","adorable","adventurous","afraid","aggressive","agonizing","agreeable","ahead","ajar","alcoholic","alert","alike","alive","alleged","alluring","aloof","amazing","ambiguous","ambitious","amuck","amused","amusing","ancient","angry","animated","annoyed","annoying","anxious","apathetic","aquatic","aromatic","arrogant","ashamed","aspiring","assorted","astonishing","attractive","auspicious","automatic","available","average","awake","aware","awesome","awful","axiomatic","bad","barbarou |
:root { | |
--font-family: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; | |
--body-color: rgba(255, 255, 255, 0.7); | |
--body-background: #282c34; | |
--header-link-color: #9b9494; | |
--header-active-link-color: #d19a66; | |
--input-border: 1px solid #2c384e; | |
--input-background: #2c384e; | |
--input-placeholder-color: #888; | |
--input-focus-border-color: #d19a66; |
If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.
To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.
Clone some repo (you've probably already done this step).
git clone [email protected]