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.
| //#include <SoftwareSerial.h> | |
| //use mega Serial 2 for serial monitor; Serial 1 on pins 19 (RX) and 18 (TX);// Serial2 on pins 17 (RX) and 16 (TX), Serial3 on pins 15 (RX) and 14 (TX). | |
| #define SSID "enter SSID here" | |
| #define PASS "enter password here" | |
| #define DST_IP "220.181.111.85" //baidu.com | |
| //SoftwareSerial dbgSerial(10, 11); // RX, TX | |
| void setup() | |
| { | |
| // Open serial communications and wait for port to open: | |
| //serial 2 is to esp8266 |
| '''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 %} |