I had a remote branch called Task/Round3.3.

I wanted to work on it locally, but have push and pull work right.

So I ran this:

git checkout -b Task/Round3.3 --track origin/Task/Round3.3

To which git said:

Branch Task/Round3.3 set up to track remote branch refs/remotes/origin/Task/Round3.3.
Switched to a new branch "Task/Round3.3"

And in .git/config, these lines were added:

[branch "Task/Round3.3"]
remote = origin
merge = refs/heads/Task/Round3.3

Now, when I checkout Task/Round3.3, I am able to say `git pull` and `git push`, and it will do the “right thing”…

After Installing Ubuntu, basically I do this:

Go to:
System -> Administration -> Software Sources -> Other Sofware, and enable partner repository.

After that, we can this on a Terminal:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install ubuntu-restricted-extras
sudo /usr/share/doc/libdvdread4/install-css.sh

[jason@dc40 AppStruct]$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm ..." to update what will be committed)
#
#       deleted:    Python/AppStruct/Application.py
#       modified:   Python/AppStruct/Database/PostgreSQL.py
#       deleted:    Python/AppStruct/Date.py
#       deleted:    Python/AppStruct/JSON.py
#       deleted:    Python/AppStruct/Util.py
#       deleted:    Python/AppStruct/__init__.py
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       Python/AppStruct/NewFile.txt
no changes added to commit (use "git add" and/or "git commit -a")

Previously, the way to handle this would be:

   git rm ...
   git rm ...
   git rm ...
   git rm ...
   git rm ...
   git add ...
   git add ...

Rather, isn’t this easier?

   git add -u
   git add .

–update | -u
Only match against already tracked files in the index rather than the working tree. That means that it will never stage new files, but that it will stage modified new contents of tracked files and that it will remove files from the index if the corresponding files in the working tree have been removed.

I’ve found that dropping and re-creating the target database is the cleanest way to restore a dumpfile — no stray relations left to cause trouble.

Unless you own all of the objects being restored, you may need to be SUPERUSER in order to have a successful restore.

The custom dump format is quite useful.  Unlike the normal sequence of SQL statements you may be used to from mysqldump (and pg_dump as well), the –format=custom option will create a compressed archive file (internally a tar file) that can be selectivly read with pg_restore.  That flexibility could come in handy if you *just* need the schema from 1 table, or *just* the data from another table.

Dump:
pg_dump –format=custom -U jason_super MyDatabase > MyDatabase.pgdump

Restore
pg_restore –exit-on-error –clean –dbname=MyDatabase MyDatabase.pgdump

Get all of the SQL
pg_restore TMTManage_2.pgdump | more

Get some of the SQL
pg_restore –schema=ACRM –table=Admin TMTManage_2.pgdump | more

The software (to this point) is nothing short of incredible.  And I’m just using the most basic features.  

Here is a graphic of Rubber Band Gun #6 internals…

I’ll have more updates as we progress deeper into the software.

-Jason