Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It's exactly opposite of what Modern C++ suppose to be.
[user] | |
name = Pavan Kumar Sunkara | |
email = pavan.sss1991@gmail.com | |
username = pksunkara | |
[init] | |
defaultBranch = master | |
[core] | |
editor = nvim | |
whitespace = fix,-indent-with-non-tab,trailing-space,cr-at-eol | |
pager = delta |
/* Exercise: Loops and Functions #43 */ | |
package main | |
import ( | |
"fmt" | |
"math" | |
) | |
func Sqrt(x float64) float64 { | |
z := float64(2.) |
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
If you use git on the command-line, you'll eventually find yourself wanting aliases for your most commonly-used commands. It's incredibly useful to be able to explore your repos with only a few keystrokes that eventually get hardcoded into muscle memory.
Some people don't add aliases because they don't want to have to adjust to not having them on a remote server. Personally, I find that having aliases doesn't mean I that forget the underlying commands, and aliases provide such a massive improvement to my workflow that it would be crazy not to have them.
The simplest way to add an alias for a specific git command is to use a standard bash alias.
# .bashrc
/* | |
* A simple example of json string parsing with json-c. | |
* | |
* clang -Wall -g -I/usr/include/json-c/ -o json_parser json_parser.c -ljson-c | |
*/ | |
#include <json.h> | |
#include <stdio.h> | |
int main() { | |
struct json_object *jobj; |
I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.
- Two developers working on independent features must never be blocked by each other
- No code freeze! Ever! For any reason!
- A developer must be able to base derivative work on another developer's work, without waiting for any third party
- Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
- Developers must be able to work on multiple features simultaneously, or at lea
echo 'export PATH=$HOME/local/bin:$PATH' >> ~/.bashrc | |
. ~/.bashrc | |
mkdir ~/local | |
mkdir ~/node-latest-install | |
cd ~/node-latest-install | |
curl http://nodejs.org/dist/node-latest.tar.gz | tar xz --strip-components=1 | |
./configure --prefix=~/local | |
make install # ok, fine, this step probably takes more than 30 seconds... | |
curl https://www.npmjs.org/install.sh | sh |
#!/usr/bin/env ruby | |
# Usage: gitio URL [CODE] | |
# | |
# Turns a github.com URL | |
# into a git.io URL | |
# | |
# Copies the git.io URL to your clipboard. | |
url = ARGV[0] | |
code = ARGV[1] |