In Git you can add a submodule to a repository. This is basically a repository embedded in your main repository. This can be very useful. A couple of usecases of submodules:
- Separate big codebases into multiple repositories.
'''A round menu that appears on a long touch | |
''' | |
from kivy.uix.widget import Widget | |
from kivy.uix.label import Label | |
from kivy.uix.behaviors import ButtonBehavior | |
from kivy.lang import Builder | |
from kivy.clock import Clock | |
from kivy.animation import Animation | |
from kivy.properties import ( | |
NumericProperty, ListProperty, ObjectProperty, DictProperty) |
When working with Git, there are two prevailing workflows are Git workflow and feature branches. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited, and the focus of this article.
If you are new to Git and Git-workflows, I suggest reading the atlassian.com Git Workflow article in addition to this as there is more detail there than presented here.
I admit, using Bash in the command line with the standard configuration leaves a bit to be desired when it comes to awareness of state. A tool that I suggest using follows these instructions on setting up GIT Bash autocompletion. This tool will assist you to better visualize the state of a branc
Nested checkbox rendering would be nice (view the sourcer for this gist)
There's no need to complete parents when child nodes are all checked.
/* | |
* Console Color | |
* | |
* Copyright (c) 2005 Joergen Ibsen | |
* | |
* Permission is hereby granted, free of charge, to any person obtaining a | |
* copy of this software and associated documentation files (the "Software"), | |
* to deal in the Software without restriction, including without limitation | |
* the rights to use, copy, modify, merge, publish, distribute, sublicense, | |
* and/or sell copies of the Software, and to permit persons to whom the |
#include <iostream> | |
#include <cstdlib> | |
class Node | |
{ | |
public: | |
Node* next; | |
int data; | |
}; |
# get into the master branch | |
git checkout master | |
# create a new branch for the changes and check it out | |
git checkout -b dev_branch | |
# stash the changes until we revert master | |
git stash | |
# go back to master |
# Committing changes to a repo via the Github API is not entirely trivial. | |
# The five-step process is outlined here: | |
# http://developer.github.com/v3/git/ | |
# | |
# Matt Swanson wrote a blog post translating the above steps into actual API calls: | |
# http://swanson.github.com/blog/2011/07/23/digging-around-the-github-api-take-2.html | |
# | |
# I was not able to find sample code for actually doing this in Ruby, | |
# either via the HTTP API or any of the gems that wrap the API. | |
# So in the hopes it will help others, here is a simple function to |
<!-- using the truncate filter --> | |
{% for post in site.posts limit:10 %} | |
<h2><a href="{{ post.url }}">{{ post.title }}</a></h2> | |
<span class="post-date">{{ post.date | date: "%B %d, %Y" }}</span> | |
{% if post.content.size > 2000 %} | |
{{ post.content | truncatewords: 300 }} <!-- bad! content gives you rendered html and you will truncate in the middle of a node --> | |
<a href="{{ post.url }}">read more</a> | |
{% else %} | |
{{ post.content }} | |
{% endif %} |
#-*- coding: utf-8 -*- | |
import urlparse | |
from django.contrib.auth import REDIRECT_FIELD_NAME, login | |
from django.contrib.auth.forms import AuthenticationForm | |
from django.http import HttpResponseRedirect | |
from django.utils.decorators import method_decorator | |
from django.views.decorators.cache import never_cache | |
from django.views.decorators.csrf import csrf_protect | |
from django.views.generic.edit import FormView | |
from django.conf import settings |