This focuses on generating the certificates for loading local virtual hosts hosted on your computer, for development only.
Do not use self-signed certificates in production ! For online certificates, use Let's Encrypt instead (tutorial).
| HTTP transfer protocols | |
| ======================= | |
| Git supports two HTTP based transfer protocols. A "dumb" protocol | |
| which requires only a standard HTTP server on the server end of the | |
| connection, and a "smart" protocol which requires a Git aware CGI | |
| (or server module). This document describes both protocols. | |
| As a design feature smart clients can automatically upgrade "dumb" | |
| protocol URLs to smart URLs. This permits all users to have the |
| " Don't try to be vi compatible | |
| set nocompatible | |
| " Helps force plugins to load correctly when it is turned back on below | |
| filetype off | |
| " TODO: Load plugins here (pathogen or vundle) | |
| " Turn on syntax highlighting | |
| syntax on |
This focuses on generating the certificates for loading local virtual hosts hosted on your computer, for development only.
Do not use self-signed certificates in production ! For online certificates, use Let's Encrypt instead (tutorial).
| # Originally published at https://gist.github.com/nzthiago/5736907 | |
| # I Customized it for SPC14 with slides | |
| # If you like it, leave me a comment | |
| # If you don't like it, complain to Github. :) | |
| [Environment]::CurrentDirectory=(Get-Location -PSProvider FileSystem).ProviderPath | |
| $rss = (new-object net.webclient) | |
| # Grab the RSS feed for the MP4 downloads |
Use case : Imagine we have just created a project with composer create-project awesone-project (currently V0.2).
2 weeks later, there is a new release (V0.3). How to update your project ?
Since composer update only updates the project dependencies, it is not what we are looking for.
Composer doesn't know about awesome-project since it's not in our composer.json.
After trying many git solutions, I've come to this :
git archive --output=changes.zip HEAD $(git diff --name-only SHA1 SHA2 --diff-filter=ACMRTUXB)
This command will check for changes between the two commits and ignore deleted files.
| let re; | |
| //this looks for the string between the slashes. it'll match hello but not HeLlo. | |
| re = /hello/; | |
| //the lower case i means be case insensitive. this will match HellO. | |
| re = /hello/i; | |
| // explaination for common search characters |
| # Windows | |
| netsh wlan show profile NOM_DU_RESEAU_WIFI key=clear | |
| # Mac | |
| security find-generic-password -wa NOM_DU_RESEAU_WIFI | |
| # Linux | |
| sudo cat /etc/NetworkManager/system-connections/NOM_DU_RESEAU_WIFI | grep psk= | |
| # From https://korben.info/une-commande-pour-retrouver-en-clair-le-mot-de-passe-dun-reseau-wifi.html |
The intermediate steps of an interactive rebase are done with a detached HEAD (partially to avoid polluting the active branch’s reflog). If you finish the full rebase operation, it will update your original branch with the cumulative result of the rebase operation and reattach HEAD to the original branch. My guess is that you never fully completed the rebase process; this will leave you with a detached HEAD pointing to the commit that was most recently processed by the rebase operation.
To recover from your situation, you should create a branch that points to the commit currently pointed to by your detached HEAD:
git branch temp git checkout temp (these two commands can be abbreviated as git checkout -b temp)
This will reattach your HEAD to the new temp branch.
| // Use Gists to store code you would like to remember later on | |
| console.log(window); // log the "window" object to the console |