In Git you can add a submodule to a repository. This is basically a sub-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 |