Committing Changes

Once you’ve changed files in a git repo, you need to first stage and then commit those changes. There are several commands involved in this, and which do what is actually pretty confusing. Here’s a breakdown:

• Staging:
  • git add . – Stages modified and new, but not deleted
  • git add -u – Stages modified and deleted, but not new
  • git add -A – Stages all
• Committing:
  • git commit – Commits staged changes
  • git commit -m "comment" – Commits staged changes with comment
• Combination:
  • git commit -a = git add -u && git commit – (See links below for subtleties)
  • git add -A && git commit -m "comment" – Stages new/modified/deleted and commits with comment in a single command
  • git add . && git commit -am "comment" – Same as above

To undo a bad commit, just re-stage what you want to and run:
git commit --amend

Branching and Merging

The major conceptual leap one has to make when coming from a version-control system like Subversion is that in Git multiple branches are handled within a single working directory.

For example, to create a new branch and switch to it, you would run the following command in your repo directory:

git checkout -b new-branch

You would then be working in a new branch without ever having changed locations on your file system.

Synchronizing Local/Remote Repositories

To get the latest version of a repo, you do:

git fetch

Then, to merge it into your current working version, you do:

git merge

OR, you can use the two-in-one command:

git pull, which is the same as git fetch followed by git merge.

To push your local repo out to the remote repo, you do:

git push

From Git pushing and pulling | Git Ready

Difference of “git add -A” and “git add .” – Stack Overflow
git add . vs git commit -a – Stack Overflow
git add -A, git commit in one command? – Stack Overflow
Git undo last commit – Stack Overflow

Other:

Git reference
Git-push is worse than useless

class MyClass(MyBaseClass):

Since Python 2.2, All classes must inherit from a base class. If the class you’re defining is a base class, it should inherit from object:

class MyClass(object):

Watch Your Base Class Syntax!

When defining base classes in Python 3.x, you’re allowed to drop the object from the definition. However, this can open the door for a seriously hard to track problem…

Depending on whether you’re using Python 2.x or Python 3.x, there’s 2 different ways to define a base class that will potentially get you 3 different results:

1) In Python 2.x
class MyClass: Old-style classes. Don’t ever use.

2) In Python 2.2 – Python 3.x
class MyClass(object): New-style classes.

3) In Python 3.x
class MyClass: Optional syntax for new-style classes. Implicitly inherits from object.

Old-style vs New-style classes

Python introduced new-style classes back in Python 2.2, and by now old-style classes are really quite old. Discussion of old-style classes is buried in the 2.x docs, and non-existant in the 3.x docs.

The problem is, the syntax for old-style classes in Python 2.x is the same as the alternative syntax for new-style classes in Python 3.x. Python 2.x is still very widely used (GAE, Web2Py), and any code (or coder) unwittingly bringing 3.x-style class definitions into 2.x code is gonna end up with some seriously outdated base objects. And because old-style classes aren’t on anyone’s radar, they likely won’t know what hit them.

For that reason, keep using the explicit class MyClass(object): style definitions for as long as 2.x code is still around.

More on this:

• Old style and new style classes in Python – Stack Overflow
• Python Types and Objects

Reserved Characters

In the language of URLs, the following ‘reserved’ characters have special meaning:

! * ' ( ) ; : @ & = + $ , / ? # [ ]

Because these characters are used to define the structure of the URL, any use of them within the URL text, whether as part of the path or part of the query string, necessitates that they be percent encoded.

Percent Encodings

Reserved characters:

Other characters:

Percent-encoding – Wikipedia

(NOTE: I’ve noticed that the following reserved characters are not consistently encoded by various encoding functions: ! * ' ( ). For example, Meyerweb’s online encoder ignores them. Not sure about various programming languages, and don’t yet have an explanation.)

Encoding Spaces

Space characters are unique in that they can be encoded using either the + sign or as the percent-encoded format %20.

Whether there are hard rules to use one format or the other is not clear to me (The + format is supposedly legacy but is still the standard format for web form GET/POST data…). Suffice it to say the two formats are both in use today and should both be handled.

Double encoding and decoding

One must make sure that a given string is only URL encoded once. Encoding an already encoded string will require decoding the same number of times.

For example:

1. Original sentence: This sentence has spaces.
2. First encoding: This%20sentence%20has%20spaces.
3. Second encoding: This%2520sentence%2520has%2520spaces.

Double decoding has less obvious consequences but can also cause incorrect results. For example, if a sentence containing a + sign is encoded once, then decoded twice, the plus sign will be treated like a space and disappear.

Further Reading

• Percent-encoding – Wikipedia
• HTML URL Encoding Reference
• URL encoding the space character: + or %20? – Stack Overflow
• In a URL Should spaces be encoded using %20 or +? – Stack Overflow
• urlencode vs rawurlencode? – Stack Overflow
• URI Encoding Done Right « Unspecified Behaviour