Introduction
GIT is a Version Control System (VCS) (aka Revision Control System (RCS), Source Code Manager (SCM)). A VCS serves as a Repository (or repo) of program codes, including all the historical revisions. It records changes to files at so-called commits in a log so that you can recall any file at any commit point.
Why VCS?
- The Repository serves as the backup (in case of code changes or disk crash).
- It is a living archive of all historical revisions. It lets you revert back to a specific version, if the need arises.
- It facilitates collaboration between team members, and serves as a project management tool.
- more...
Git was initially designed and developed by Linus Torvalds, in 2005, to support the development of the Linux kernel.
GIT is a Distributed Version Control System (DVCS). Other popular VCSes include:
- The standalone and legacy Unix's RCS (Revision Control System).
- Centralized Client-Server Version Control System (CVCS): CVS (Concurrent Version System), SVN (Subversion) and Perforce.
- Distributed VCS (DVCS): GIT, Merurial, Bazaar, Darcs.
The mother site for Git is http://git-scm.com.
Setting Up Git
You need to setup Git on your local machine, as follows:
- Download & Install:
- For Windows and Mac, download the installer from http://git-scm.com/downloads and run the downloaded installer.
- For Ubuntu, issue command "
sudo apt-get install git
".
- Customize Git:
Issue "git config
" command (for Windows, run "Git Bash" from the Git installed directory. For Ubuntu/Mac, launch a "Terminal"):// Set up your username and email (to be used in labeling your commits) $ git config --global user.name "your-name" $ git config --global user.email<EMAIL_ADDRESS>The settings are kept in "<GIT_HOME>/etc/gitconfig
" (of the GIT installed directory) and "<USER_HOME>/.gitconfig
" (of the user's home directory.
You can issue "git config --list
" to list the settings:$ git config --list<EMAIL_ADDRESS>user.name=xxxxxx
Git Basics
Git Commands
Git provides a set of simple, distinct, standalone commands developed according to the "Unix toolkit" philosophy - build small, interoperable tools.
To issue a command, start a "Terminal" (for Ubuntu/Mac) or "Git Bash" (for Windows):
$ git <command> <arguments>
The commonly-used commands are:
- init, clone, config: for starting a Git-managed project.
- add, mv, rm: for staging file changes.
- commit, rebase, reset, tag:
- status, log, diff, grep, show: show status
- checkout, branch, merge, push, fetch, pull
Help and Manual
The best way to get help these days is certainly googling.
To get help on Git commands:
$ git help <command>
// or
$ git <command> --help
The GIT manual is bundled with the software (under the "doc
" directory), and also available online @ http://git-scm.com/docs.
Getting Started with Local Repo
There are 2 ways to start a Git-managed project:
- Starting your own project;
- Cloning an existing project from a GIT host.
We shall begin with "Starting your own project" and cover "Cloning" later @ "Clone a Project from a Remote Repo".
Setup the Working Directory for a New Project
Let's start a programming project under the working directory called "hello-git
", with one source file "Hello.java
" (or "Hello.cpp
", or "Hello.c
") as follows:
// Hello.java
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, world from GIT!");
}
}
Compile the "Hello.java
" into "Hello.class
" (or "Hello.cpp
" or "Hello.c
" into "Hello.exe
").
It is also highly recommended to provide a "README.md
" file (a text file in a so-called "Markdown" syntax such as "GitHub Flavored Markdown") to describe your project:
// README.md
This is the README file for the Hello-world project.
Now, we have 3 files in the working tree: "Hello.java
", "Hello.class
" and "README.md
". We do not wish to track the ".class
" as they can be reproduced from ".java
".
Initialize a new Git Repo (git init)
To manage a project under Git, run "git init
" at the project root directory (i.e., "hello-git
") (via "Git Bash" for Windows, or "Terminal" for Ubuntu/Mac):
// Change directory to the project directory $ cd /path-to/hello-git // Initialize Git repo for this project $ git init Initialized empty Git repository in /path-to/hello-git/.git/ $ ls -al drwxr-xr-x 1 xxxxx xxxxx 4096 Sep 14 14:58 .git -rw-r--r-- 1 xxxxx xxxxx 426 Sep 14 14:40 Hello.class -rw-r--r-- 1 xxxxx xxxxx 142 Sep 14 14:32 Hello.java -rw-r--r-- 1 xxxxx xxxxx 66 Sep 14 14:33 README.md
A hidden sub-directory called ".git
" will be created under your project root directory (as shown in the above "ls -a
" listing), which contains ALL Git related data.
Take note that EACH Git repo is associated with a project directory (and its sub-directories). The Git repo is completely contain within the project directory. Hence, it is safe to copy, move or rename the project directory. If your project uses more than one directories, you may create one Git repo for EACH directory, or use symlinks to link up the directories, or ... (?!).
Git Storage Model
The local repo after "git init
" is empty. You need to explicitly deposit files into the repo.
Before we proceed, it is important to stress that Git manages changes to files between so-called commits. In other words, it is a version control system that allows you to keep track of the file changes at the commits.
Staging File Changes for Tracking (git add <file>...)
 to include in what will be committed) Hello.class Hello.java README.md nothing added to commit but untracked files present (use "git add" to track)
By default, we start on a branch called "master
". We will discuss "branch" later.
In Git, the files in the working tree are either untracked or tracked. Currently, all 3 files are untracked. To stage a new file for tracking, use "git add <file>...
" command.
 to unstage) new file: README.md Untracked files: (use "git add <file>..." to include in what will be committed) Hello.class Hello.java // You can use wildcard * in the filename // Add all Java source files into Git repo $ git add *.java // You can also include multiple files in the "git add" // E.g., // git add Hello.java README.md $ git status On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: Hello.java new file: README.md Untracked files: (use "git add <file>..." to include in what will be committed) Hello.class
The command "git add <file>...
" takes one or more filenames or pathnames with possibly wildcards pattern. You can also use "git add .
" to add all the files in the current directory (and all sub-directories). But this will include "Hello.class
", which we do not wish to be tracked.
When a new file is added, it is staged (or indexed, or cached) in the staging area (as shown in the GIT storage model), but NOT yet committed.

The staging area allows you to group related file changes and commit them together.
Committing File Changes (git commit)
The "git commit
" command commits ALL the file changes in the staging area.  to include in what will be committed) Hello.class nothing added to commit but untracked files present (use "git add" to track)
Viewing the Commit Data (git log)
Git records several pieces of metadata for every commit, which includes a log message, timestamp, the author's username and email (set during customization).
You can use "git log
" to list the commit data; or "git log --stat
" to view the file statistics:
$ git log commit 858f3e71b95271ea320d45b69f44dc55cf1ff794 Author: username <email> Date: Thu Nov 29 13:31:32 2012 +0800 First commit $ git log --stat commit 858f3e71b95271ea320d45b69f44dc55cf1ff794 Author: username <email> Date: Thu Nov 29 13:31:32 2012 +0800 First commit Hello.java | 6 ++++++ README.md | 2 ++ 2 files changed, 8 insertions(+)
Each commit is identified by a 40-hex-digit SHA-1 hash code. But we typcially use the first 7 hex digits to reference a commit, as highlighted.
To view the commit details, use "git log -p
", which lists all the patches (or changes).
$ git log -p commit 858f3e71b95271ea320d45b69f44dc55cf1ff794 Author: username <email> Date: Thu Nov 29 13:31:32 2012 +0800 First commit diff --git a/Hello.java b/Hello.java new file mode 100644 index 0000000..dc8d4cf --- /dev/null +++ b/Hello.java @@ -0,0 +1,6 @@ +// Hello.java +public class Hello { + public static void main(String[] args) { + System.out.println("Hello, world from GIT!"); + } +} diff --git a/README.md b/README.md new file mode 100644 index 0000000..9565113 --- /dev/null +++ b/README.md @@ -0,0 +1,2 @@ +// README.md +This is the README file for the Hello-world project.
Below are more options of using "git log
":
$ git log --oneline // Display EACH commit in one line. $ git log --author="<author-name-pattern>" // Display commits by author $ git log <file-pattern> // Display commits for particular file(s) // EXAMPLES $ git log --author="Tan Ah Teck" -p Hello.java // Display commits for file "Hello.java" by a particular author
File Status (git status)
A file could be untracked or tracked.
As mentioned, Git tracks file changes at commits. In Git, changes for a tracked file could be:
- unstaged (in Working Tree) - called unstaged changes,
- staged (in Staging Area or Index or Cache) - called staged changes, or
- committed (in local repo object database).
The files in "working tree" or "staging area" could have status of unmodified, added, modified, deleted, renamed, copied, as reported by "git status
".
The "git status
" output is divided into 3 sections: "Changes not staged for commit" for the unstaged changes in "working tree", "Changes to be committed" for the staged changes in the "staging area", and "Untracked files". In each section, It lists all the files that have been changed, i,e., files having status other than unmodified.
When a new file is created in the working tree, it is marked as new in working tree and shown as an untracked file. When the file change is staged, it is marked as new (added) in the staging area, and unmodified in working tree. When the file change is committed, it is marked as unmodified in both the working tree and staging area.
When a committed file is modified, it is marked as modified in the working tree and unmodified in the staging area. When the file change is staged, it is marked as modified in the staging area and unmodified in the working tree. When the file change is committed, it is marked as unmodified in both the working tree and staging area.
For example, made some changes to the file "Hello.java
", and check the status again:
// Hello.java public class Hello { public static void main(String[] args) { System.out.println("Hello, world from GIT!"); System.out.println("Changes after First commit!"); } }
$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Hello.java Untracked files: (use "git add <file>..." to include in what will be committed) Hello.class no changes added to commit (use "git add" and/or "git commit -a")
The "Hello.java
" is marked as modified in the working tree (under "Changes not staged for commit"), but unmodified in the staging area (not shown in "Changes to be committed").
You can inspect all the unstaged changes using "git diff
" command (or "git diff <file>
" for the specified file). It shows the file changes in the working tree since the last commit:
$ git diff
diff --git a/Hello.java b/Hello.java
index dc8d4cf..f4a4393 100644
--- a/Hello.java
+++ b/Hello.java
@@ -2,5 +2,6 @@
public class Hello {
public static void main(String[] args) {
System.out.println("Hello, world from GIT!");
+ System.out.println("Changes after First commit!");
}
}
The older version (as of last commit) is marked as ---
and new one as +++
. Each chunk of changes is delimited by "@@ -<old-line-number>,<number-of-lines> +<new-line-number>,<number-of-lines> @@
". Added lines are marked as +
and deleted as -
. In the above output, older version (as of last commit) from line 2 for 5 lines and the modified version from line 2 for 6 lines are compared. One line (marked as +) is added.
Stage the changes of "Hello.java
" by issuing the "git add <file>...
":
$ git add Hello.java $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: Hello.java Untracked files: (use "git add <file>..." to include in what will be committed) Hello.class
Now, it is marked as modified in the staging area ("Changes to be committed"), but unmodified in the working tree (not shown in "Changes not staged for commit").
Now, the changes have been staged. Issuing an "git diff
" to show the unstaged changes results in empty output.
You can inspect the staged change (in the staging area) via "git diff --staged
" command:
// List all "unstaged" changes for all files (in the working tree) $ git diff // empty output - no unstaged change // List all "staged" changes for all files (in the staging area) $ git diff --staged diff --git a/Hello.java b/Hello.java index dc8d4cf..f4a4393 100644 --- a/Hello.java +++ b/Hello.java @@ -2,5 +2,6 @@ public class Hello { public static void main(String[] args) { System.out.println("Hello, world from GIT!"); + System.out.println("Changes after First commit!"); } } // The "unstaged" changes are now "staged".
 to include in what will be committed) Hello.class nothing added to commit but untracked files present (use "git add" to track)
Once the file changes are committed, it is marked as unmodified in the staging area (not shown in "Changes to be committed").
Both "git diff
" and "git diff --staged
" return empty output, signalling there is no "unstaged" and "staged" changes.
The stage changes are cleared when the changes are committed; while the unstaged changes are cleared when the changes are staged.
Issue "git log
" to list all the commits:
$ git log commit 96efc96f0856846bc495aca2e4ea9f06b38317d1 Author: username <email> Date: Thu Nov 29 14:09:46 2012 +0800 Second commit commit 858f3e71b95271ea320d45b69f44dc55cf1ff794 Author: username <email> Date: Thu Nov 29 13:31:32 2012 +0800 First commit
Check the patches for the latest commit via "git log -p -1
", with option -n
to limit to the last n
commit:
$ git log -p -1 commit 96efc96f0856846bc495aca2e4ea9f06b38317d1 Author: username <email> Date: Thu Nov 29 14:09:46 2012 +0800 Second commit diff --git a/Hello.java b/Hello.java index dc8d4cf..ede8979 100644 --- a/Hello.java +++ b/Hello.java @@ -2,5 +2,6 @@ public class Hello { public static void main(String[] args) { System.out.println("Hello, world from GIT!"); + System.out.println("Changes after First commit!"); } }
I shall stress again Git tracks the "file changes" at each commit over the previous commit.
The .gitignore File
All the files in the Git directory are either tracked or untracked. To ignore files (such as .class
, .o
, .exe
which could be reproduced from source) from being tracked and remove them from the untracked file list, create a ".gitignore
" file in your project directory, which list the files to be ignored, as follows:
# .gitignore # Java class files *.class # Executable files *.exe # Object and archive files # Can use regular expression, e.g., [oa] matches either o or a *.[oa] # temp sub-directory (ended with a directory separator) temp/
There should NOT be any trailing comments for filename. You can use regexe for matching the filename/pathname patterns, e.g. [oa]
denotes either o
or a
. You can override the rules by using the inverted pattern (!
), e.g., Adding !hello.exe
includes the hello.exe
although *.exe
are excluded.
Now, issue a "git status
" command to check the untracked files.
$ git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore nothing added to commit but untracked files present (use "git add" to track)
Now, "Hello.class
" is not shown in "Untracked files".
Typically, we also track and commit the .gitignore
file.
$ git add .gitignore $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: .gitignore $ git commit -m "Added .gitignore" [master 711ef4f] Added .gitignore 1 file changed, 14 insertions(+) create mode 100644 .gitignore $ git status On branch master nothing to commit, working directory clean
Setting up Remote Repo
- Sign up for a GIT host, such as Github https://github.com/signup/free (Unlimited for public projects; fee for private projects); or BitBucket @ https://bitbucket.org/ (Unlimited users for public projects; 5 free users for private projects; Unlimited for Academic Plan); among others.
- Login to the GIT host. Create a new remote repo called "
test
". - On your local repo (let's continue to work on our "
hello-git
" project), set up the remote repo's name and URL via "git remote add <remote-name> <remote-url>
" command.
By convention, we shall name our remote repo as "origin
". You can find the URL of a remote repo from the Git host. The URL may take the form of HTTPS or SSH. Use HTTPS for simplicity.// Change directory to your local repo's working directory $ cd /path-to/hello-git // Add a remote repo called "origin" via "git remote add <remote-name> <remote-url>" // For examples, $ git remote add origin https://github.com/your-username/test.git // for GitHub $ git remote add origin<EMAIL_ADDRESS>// for Bitbucket
You can list all the remote names and their corresponding URLs via "git remote -v
", for example,// List all remote names and their corresonding URLs $ git remote -v origin https://github.com/your-username/test.git (fetch) origin https://github.com/your-username/test.git (push)
Now, you can manage the remote connection, using a simple name instead of the complex URL.
- Push the commits from the local repo to the remote repo via "
git push -u <remote-name> <local-branch-name>
".
By convention, the main branch of our local repo is called "master
" (as seen from the earlier "git status
" output). We shall discuss "branch" later.// Push all commits of the branch "master" to remote repo "origin" $ git push origin master Username for 'https://github.com': ****** Password for<EMAIL_ADDRESS>******* Counting objects: 10, done. Delta compression using up to 8 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 1.13 KiB | 0 bytes/s, done. Total 10 (delta 1), reused 0 (delta 0) To https://github.com/your-username/test.git * [new branch] master -> master Branch master set up to track remote branch master from origin.
- Login to the GIT host and select the remote repo "test", you shall find all the committed files.
- On your local system, make some change (e.g., on "
Hello.java
"); stage and commit the changes on the local repo; and push it to the remote. This is known as the "Edit/Stage/Commit/Push" cycle.// Hello.java public class Hello { public static void main(String[] args) { System.out.println("Hello, world from GIT!"); System.out.println("Changes after First commit!"); System.out.println("Changes after Pushing to remote!"); } }
$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working dire modified: Hello.java no changes added to commit (use "git add" and/or "git commit -a") // Stage file changes $ git add *.java $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: Hello.java // Commit all staged file changes $ git commit -m "Third commit" [master 744307e] Third commit 1 file changed, 1 insertion(+) // Push the commits on local master branch to remote $ git push origin master Username for 'https://github.com': ****** Password for<EMAIL_ADDRESS>****** Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 377 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To https://github.com/your-username/test.git 711ef4f..744307e master -> master
Again, login to the remote to check the committed files.
Cloning a Project from a Remote Repo (git clone <remote-url>)
As mentioned earlier, you can start a local GIT repo either running "git init
" on your own project, or "git clone <remote-url>
" to copy from an existing project.
Anyone having read access to your remote repo can clone your project. You can also clone any project in any public remote repo.
The "git clone <remote-url>
" initializes a local repo and copies all files into the working tree. You can find the URL of a remote repo from the Git host.
// SYNTAX // ====== $ git clone <remote-url> // <url>: can be https (recommended), ssh or file. // Clone the project UNDER the current directory // The name of the "working directory" is the same as the remote project name $ git clone <remote-url> <working-directory-name> // Clone UNDER current directory, use the given "working directory" name // EXAMPLES // ======== // Change directory (cd) to the "parent" directory of the project directory $ cd path-to-parent-of-the-working-directory // Clone our remote repo "test" into a new working directory called "hello-git-cloned" $ git clone https://github.com/your-username/test.git hello-git-cloned Cloning into 'hello-git-cloned'... remote: Counting objects: 13, done. remote: Compressing objects: 100% (11/11), done. remote: Total 13 (delta 2), reused 13 (delta 2) Unpacking objects: 100% (13/13), done. Checking connectivity... done. // Verify $ cd hello-git-cloned $ ls -a . .. .git .gitignore Hello.java README.md $ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean
The "git clone
" automatically creates a remote name called "origin
" mapped to the cloned remote-URL. You can check via "git remote -v
":
// List all the remote names
$ git remote -v
origin https://github.com/your-username/test.git (fetch)
origin https://github.com/your-username/test.git (push)
Summary of Basic "Edit/Stage/Commit/Push" Cycle
// Edit (Create, Modified, Rename, Delete) files, // which produces "unstaged" file changes. // Stage file changes, which produces "Staged" file changes $ git add <file> // for new and modified files $ git rm <file> // for deleted files $ git mv <old-file-name> <new-file-name> // for renamed file // Commit (ALL staged file changes) $ git commit -m <message> // Push $ git push <remote-name> <local-branch-name>
More on Staged and Unstaged Changes
If you modify a file, stage the changes and modify the file again, there will be staged changes and unstaged changes for that file.
For example, let's continue the "hello-git
" project. Add one more line to "README.md
" and stage the changes:
// README.md
This is the README file for the Hello-world project.
Make some changes and staged.
$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: modified: README.md $ git add README.md $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: modified: README.md
Before the changes are committed, suppose we modify the file again:
// README.md
This is the README file for the Hello-world project.
Make some changes and staged.
Make more changes before the previous changes are committed.
$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: modified: README.md Changes not staged for commit: modified: README.md // Now, "README.md" has both unstaged and staged changes. // Show the staged changes $ git diff --staged diff --git a/README.md b/README.md index 9565113..b2e9afb 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,3 @@ // README.md This is the README file for the Hello-world project. +Make some changes and staged. // Show the unstaged changes $ git diff diff --git a/README.md b/README.md index b2e9afb..ca6622a 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,4 @@ // README.md This is the README file for the Hello-world project. Make some changes and staged. +Make more changes before the previous changes are committed. // Stage the changes $ git add README.md $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: modified: README.md // Show staged changes $ git diff --staged diff --git a/README.md b/README.md index 9565113..ca6622a 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,4 @@ // README.md This is the README file for the Hello-world project. +Make some changes and staged. +Make more changes before the previous changes are committed. // Commit the staged changes $ git commit -m "Unstaged vs. Staged Changes" [master a44199b] Unstaged vs. Staged Changes 1 file changed, 2 insertions(+), 0 deletion(-)
Take note that the stage changes are cleared when the changes are committed; while the unstaged changes are cleared when the changes are staged.
For convenience, you can also use the "git-gui" tool to view the unstaged and staged changes.
Git GUI Tools
Git-GUI (Windows)
For convenience, Git provides a GUI tool, called git-gui
, which can be used to perform all tasks and view the commit log graphically.
Install "Git-Gui".
To run the git-gui
, you can right-click on the project folder and choose "Git Gui"; or launch the Git-bash shell and run "git gui
" command.
To view the log, choose "Repository" ⇒ "Visualize master's history", which launches the "gitk". You can view the details of each commit.
You can also view each of the file via "Repository" ⇒ "Browse master's Files" ⇒ Select a file.
Git-gui is bundled with Git. To launch git-gui, right click on the working directory and choose "git gui", or run "git gui
" command on the Git-Bash shell.
[TODO]
EGit Plugin for Eclipse
[TODO]
Tagging
Tag (or label) can be used to tag a specific commit as being important, for example, to mark a particular release. The release is often marked in this format: version-number
.release-no.modificaton-no
(e.g., v1.1.5
) or or version-number
.release-no.upgrade-no_modificaton-no
(e.g., v1.7.0_26
).
I recommend that you commit your code and push it to the remote repo as often as needed (e.g., daily), to BACKUP your code. When you code reaches a stable point (in turn of functionality), create a tag to mark the commit, which can then be used for CHECKOUT, if you need to show your code to others.
Listing Tags (git tag)
To list the existing tags, use "git tag
" command.
Types of Tags - Lightweight Tags and Annotated Tags
There are two kinds of tags: lightweight tag and annotated tag. Lightweight tag is simply a pointer to a commit. Annotated tag contains annotations (meta-data) and can be digitally signed and verified.
Creating an Annotated Tag (git tag -a <tag-name> -m <message>)
To create an annotated tag at the latest commit, use "git tag -a <tag-name> -m <message>
", where -a
option specifies annotation tag having meta-data. For example,
$ git tag -a v1.0.0 -m "First production system" // List all tags $ git tag v1.0.0 // Show tag details $ git show v1.0.0 // Show the commit point and working tree
To create a tag for an earlier commit, you need to find out the commit's name (first seven character hash code) (via "git log
"), and issue "git tag -a <tag-name> -m <message> <commit-name>
". For example,
$ git log ...... commit 7e7cb40a9340691e2b16a041f7185cee5f7ba92e ...... Commit 3 $ git tag -a "v0.9.0" -m "Last pre-production release" 7e7cb40 // List all tags $ git tag v0.9.0 v1.0.0 // Show details of a tag $ git show v0.9.0 ......
[TODO] Diagram
Creating Lightweight Tags (git tag <tag-name>)
To create a lightweight tag (without meta-data), use "git tag <tag-name>
" without the -a
option. The lightweight tag stores only the commit hash code.
Signed Tags
You can signed your tags with your private key, with -s
option instead of -a
.
To verify a signed tag, use -v
option and provide the signer's public key.
[TODO] Example
Pushing to Remote Repo
By default, Git does not push tags (and branches) to remote repo. You need to push them explicitly, via "git push origin <tag-name>
" for a particular tag or "git push origin --tags
" for all the tags.
Branching/Merging
Git's Data Structures
Git has two primary data structures:
- an immutable, append-only object database (or local repo) that stores all the commits and file contents;
- a mutable staging area (or index, or cache) that caches the staged information.
The staging area serves as the connection between object database and working tree (as shown in the storage model diagram). It serves to avoid volatility, and allows you to stage ALL the file changes before issuing a commit, instead of committing individual file change. Changes to files that have been explicitly added to the index (staging area) via "git add <file>
" are called staged changes. Changes that have not been added are called unstaged changes. Staged and unstaged changes can co-exist. Performing a commit copies the statged changes into object database (local repo) and clears the index. The unstaged changes remain in working tree.
The object database contains these objects:
- Each version of a file is represented by a blob (binary large object - a file that can contain any data: binaries or characters). A blob holds the file data only, without any metadata - not even the filename.
- A snapshot of the working tree is represented by a tree object, which links the blobs and sub-trees for sub-directories.
- A commit object points to a tree object, i.e., the snapshot of the working tree at the point the commit was created. It holds metadata such as timestamp, log message, author's and committer's username and email. It also references its parent commit(s), except the root commit which has no parent.  A commit, where new branch is created, has more than one children. By referencing through the chain of parent commit(s), you can discover the history of the project.
Each object is identified (or named) by a 160-bit (or 40 hex-digit) SHA-1 hash value of its contents (i.e., a content-addressable name). Any tiny change to the contents produces a different hash value, resulted in a different object. Typically, we use the first 7 hex-digit prefix to refer to an object, as long as there is no ambiguity.
There are two ways to refer to a particular commit: via a branch or a tag.
- A branch is a mobile reference of commit. It moves forward whenever commit is made on that branch.
- A tag (like a label) marks a particular commit. Tag is often used for marking the releases.
Branching
Branching allows you and your team members to work on different aspects of the software concurrently (on so-called feature branches), and merge into the master
branch as and when they completes. Branching is the most important feature in a concurrent version control system.
A branch in Git is a lightweight movable pointer to one of the commits. For the initial commit, Git assigns the default branch name called master
and sets the master
branch pointer at the initial commit. As you make further commits on the master
branch, the master
branch pointer move forward accordingly. Git also uses a special pointer called HEAD
to keep track of the branch that you are currently working on. The HEAD
always refers to the latest commit on the current branch. Whenever you switch branch, the HEAD
also switches to the latest commit on the branch switched.
Example
For example, let's create a Git-managed project called git_branch_test
with only the a single-line README.md
file:
This is the README. My email is<EMAIL_ADDRESS>$ git init $ git add README.md $ git commit -m "Commit 1" // Append a line in README.md: This line is added after Commit 1 $ git status $ git add README.md $ git commit -m "Commit 2" // Append a line in README.md: This line is added after Commit 2 $ git status $ git add README.md $ git commit -m "Commit 3" // Show all the commits (oneline each) $ git log --oneline 44fdf4c Commit 3 51f6827 Commit 2 fbed70e Commit 1
Creating a new Branch (git branch <branch-name>)
You can create a new branch via "git branch <branch-name>
" command. When you create a new branch (says devel
, or development
), Git creates a new branch pointer for the branch devel
, pointing initially at the latest commit on the current branch master
.
$ git branch devel
Take note that when you create a new branch, the HEAD pointer is still pointing at the current branch.
Branch Names Convention
master
branch: the production branch with tags for the various releases.development
(ornext
ordevel
) branch: developmental branch, to be merged into master if and when completes.- topics branch: a short-live branch for a specific topics, such as introducing a feature (for the
devel
branch) or fixing a bug (for themaster
branch).
Switching to a Branch (git checkout <branch-name>)
Git uses a special pointer called HEAD
to keep track of the branch that you are working on. The "git branch <branch-name>
" command simply create a branch, but does not switch to the new branch. To switch to a branch, use "git checkout <branch-name>
" command. The HEAD
pointer will be pointing at the switched branch (e.g., devel
).
$ git checkout devel Switched to branch 'devel'
Alternatively, you can use "git checkout -b <branch-name>
" to create a new branch and switch into the new branch.
If you switch to a branch and make changes and commit. The HEAD
pointer moves forward in that branch.
// Append a line in README.md: This line is added on devel branch after Commit 3 $ git status // NOTE "On branch devel" $ git add README.md $ git commit -m "Commit 4" [devel c9b88d9] Commit 4
You can switch back to the master
branch via "git checkout master
". The HEAD
pointer moves back to the last commit of the master
branch, and the working directory is rewinded back to the latest commit on the master
branch.
$ git checkout master
Switched to branch 'master'
// Check the content of the README.md, which is reminded back to Commit 3
If you continue to work on the master
branch and commit, the HEAD
pointer moves forward on the master
branch. The two branches now diverge.
// Append a line in README.md: This line is added on master branch after Commit 4 $ git status // NOTE "On branch master" $ git add README.md $ git commit -m "Commit 5" [master 6464eb8] Commit 5
If you check out the devel
branch, the file contents will be rewinded back to Commit-4.
$ git checkout devel
// Check file contents
Merging Two Branches (git merge <branch-name>)
To merge two branches, says master
and devel
, check out the first branch, e,g, master
, (via "git checkout <branch-name>
") and merge with another branch, e.g., devel
, via command "git merge <branch-name>
".
Fast-Forward Linear Merge
If the branch to be merged is a direct descendant, Git performs fast forward by moving the HEAD
pointer forward. For example, suppose that you are currently working on the devel
branch at commit-4, and the master
branch's latest commit is at commit-3:
$ git checkout master // Let discard the Commit-5 totally and rewind to commit-3 on master branch // This is solely for illustration!!! Do this with great care!!! $ git reset --hard HEAD~1 HEAD is now at 7e7cb40 Commit 3 // HEAD~1 moves the HEAD pointer back by one commit (-1) // --hard also resets the working tree // Check the file contents $ git merge devel Updating 7e7cb40..4848c7b Fast-forward README.md | 1 + 1 file changed, 1 insertion(+) // Check the file contents
Take note that no new commit is created.
3-Way Merge
If the two branches are diverged, git automatically searches for the common ancestor commit and performs a 3-way merge. If there is no conflict, a new commit will be created.
If git detects a conflict, it will pause the merge and issue a merge conflict and ask you to resolve the conflict manually. The file is marked as unmerged. You can issue "git status
" to check the unmerged files, study the details of the conflict, and decide which way to resolve the conflict. Once the conflict is resolve, stage the file (via "git add <file>
"). Finally, run a "git commit
" to finalize the 3-way merge (the same Edit/Stage/Commit cycle).
$ git checkout master // undo the Commit-4, back to Commit-3 $ git reset --hard HEAD~1 HEAD is now at 7e7cb40 Commit 3 // Change the email to<EMAIL_ADDRESS>$ git add README.md $ git commit -m "Commit 5" $ git checkout devel // undo the Commit-4, back to Commit-3 $ git reset --hard HEAD~1 // Change the email to<EMAIL_ADDRESS>to trigger conflict $ git add README.md $ git commit -m "Commit 4" // Let's do a 3-way merge with conflict $ git checkout master $ git merge devel Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. $ git status # On branch master # You have unmerged paths. # (fix conflicts and run "git commit") # # Unmerged paths: # (use "git add <file>..." to mark resolution) # both modified: README.md no changes added to commit (use "git add" and/or "git commit -a")
The conflict file is marked as follows (in "git status
"):
<<<<<<< HEAD This is the README. My email is<EMAIL_ADDRESS>======= This is the README. My email is<EMAIL_ADDRESS>>>>>>>> devel This line is added after Commit 1 This line is added after Commit 2
You need to manually decide which way to take, or you could discard both by setting the email to<EMAIL_ADDRESS>$ git add README.md $ git commit -m "Commit 6"
Take note that In a 3-way merge, a new commit will be created in the process (unlike fast-forward merge).
Deleting a Merged Branch (git branch -d <branch-name>)
The merged branch (e.g., devel
) is no longer needed. You can delete it via "git branch -d <branch-name>
".
$ git branch -d devel
Deleted branch devel (was a20f002).
// Create the development branch again at the latest commit
$ git branch devel
Rebasing Branch (git rebase)
The primary purpose for rebasing is to maintain a linear project history. For example, if you checkout a devel
branch and work on commit-5 and commit-6, instead of doing a 3-way merge into the master
branch and subsequently remove the devel
branch, you can rebase the commit-5 and commit-6, on commit-4, and perform a linear forward merge to maintain all the project history. New commits (7 and 8) will be created for the rebased commit (5 and 6).
The syntax is:
// SYNTAX $ git rebase <base-name> // <base-name> could be any kind of commit reference // (such as an commit-name, a branch name, a tag, // or a relative reference to HEAD).
  The syntaxes are:
$ git checkout <branch-name> $ git checkout <commit-name> $ git checkout <commit-name> <filename>
When you checkout
a commit, Git switches into so-called "Detached HEAD" state, i.e., the HEAD detached from the tip of a branch. Suppose that you continue to work on the detached HEAD on commit-5, and wish to merge the commit-5 back to master
. You checkout the master branch, but there is no branch name for your to reference the commit-5!!!
In Summary, you can use "git checkout <commit-name>
" to inspect a commit. BUT you should always work on a branch, NOT on a detached HEAD.
More on "git reset" and "git reset --hard"
[TODO] examples and diagram
$ git reset <file> // Unstage the changes of <file> from staging area, // not affecting the working tree. $ git reset // Reset the staging area // Remove all changes (of all files) from staging area, // not affecting the working tree. $ git reset --hard // Reset the staging area and working tree to match the // recent commit (i.e., discard all changes since the // last commit). $ git reset <commit-name> // Move the HEAD of current branch to the given commit, // not affecting the working tree. $ git reset --hard <commit-name> // Reset both staging area and working tree to the given // commit, i.e., discard all changes after that commit.
[TODO] Diagram
[TODO] --soft option
git revert <commit-name>
The "git revert
" undoes a commit. But, instead of removing the commit from the project history, it undos the changes introduced by the commit and appends a new commit with the resulting content. This prevents Git from losing history. "git revert
" is a safer way comparing with "git reset
".
// SYNTAX $ git revert <commit-name> // EXAMPLE [TODO] example and diagram
Summary of Work Flows
Setting up GIT and "Edit/Stage/Commit/Push" Cycle
Step 1: Install GIT.
- For Windows and Mac, download the installer from http://git-scm.com/downloads and run the downloaded installer.
- For Ubuntu, issue command "
sudo apt-get install git
".
For Windows, use "git-bash
" command shell provided by Windows installer to issue command. For Mac/Ubuntu, use "Terminal".
Step 2: Configuring GIT:
// Setup your username and email to be used in labeling commits
$ git config --global user.email<EMAIL_ADDRESS>$ git config --global user.name "your-name"
Step 3: Set up GIT repo for a project. For example, we have a project called "olas1.1
" located at "/usr/local/olas/olas1.1
".
$ cd /usr/local/olas/olas1.1 // Initialize the GIT repo $ git init $ ls -al // Check for ".git" directory
Create a "README.md
" (or "README.textile
" if you are using Eclipse's WikiText in "textile" markup) under your project directory to describe the project.
Step 4: Start "Edit/Stage/Commit/Push" cycles.
Create/Modify files. Stage files into the staging area via "git add <file>
".
// Check the status $ git status ...... // Add files into repo $ git add README.md $ git add www ...... // Check the status $ git status ......
Step 5: Create a ".gitignore
" (in the project base directory) to exclude folders/files from being tracked by GIT. Check your "git status
" output to decide which folders/files to be ignored.
For example,
# ignore files and directories beginning with dot .* # ignore directories beginning with dot (a directory ends with a slash) .*/ # ignore these files and directories www/test/ www/.* www/.*/
The trailing slash indicate directory (and its sub-directories and files).
If you want the ".gitignore
" to be tracked (which is in the ignore list):
$ git add -f .gitignore
// -f to override the .gitignore
Step 6: Commit.
$ git status
......

Step 7: Push to the Remote Repo (for backup, version control, and collaboration).
You need to first create a repo (says olas) in a remote GIT host, such as GitHub or BitBucket. Take note of the remote repo URL, e.g<EMAIL_ADDRESS>$ cd /path-to/local-repo // Add a remote repo name called "origin" mapped to the remote URL $ git remote add origin https://hostname/username/olas.git // Push the "master" branch to the remote "origin" // "master" is the default branch name of your local repo after init. $ git push origin master
Check the remote repo for the files committed.
Step 8: Work on the source files, make changes, commit and push to remote repo.
// Check the files modified $ git status ...... // Stage for commit the modified files $ git add .... ...... // Commit (with a message) $ git commit -m "commit-message" // Push to remote repo $ git push origin master
Step 9: Create a "tag" (for version number).
// Tag a version number to the current commit $ git tag -a v1.1 -m "Version 1.1" // -a to create an annotated tag, -m to provide a message // Display all tags $ git tag ...... // Push the tags to remote repo // ("git push -u origin master" does not push the tags) $ git push origin --tags
Branch and Merge Workflow
It is a good practice to freeze the "master
" branch for production; and work on a development branch (says "devel
") instead. You may often spawn a branch to fix a bug in the production.
// Create a branch called "devel" and checkout. // The "devel" is initially synchronized with the "master" branch. $ git checkout -b devel // same as: // $ git branch devel // $ git checkout // Edit/Stage/Commit $ git add <file> $ git commit -m "commit-message" // To merge the "devel" into the production "master" branch $ git checkout master $ git merge devel // Push both branches to remote repo $ git push origin master devel // Checkout the "devel" branch and continue... $ git checkout devel // Edit/Stage/Commit/Push // Need to fix a bug in production (in "master" branch) $ git checkout master // Spawn a "fix" branch to fix the bug, and merge with the "master" branch // To remove the "devel" branch (if the branch is out-of-sync) $ git branch -d devel // To re-create the "devel" branch $ git checkout -b devel
Viewing the Commit Graph (gitk)
You can use the "git-gui" "gitk" tool to view the commit graph.
To run the git-gui, you can right-click on the project folder and choose "Git Gui"; or launch the Git-bash shell and run "git gui
" command.
To view the commit graph, choose "Repository" ⇒ "Visualize master's history", which launches the "gitk". You can view the details of each commit.
Collaboration
Reference: https://www.atlassian.com/git/tutorials/making-a-pull-request/how-it-works.
Synchronizing Remote and Local: Fetch/Merge, Pull and Push
Setup up a remote repo (revision)
As described earlier, you can use "git remote
" command to set up a "remote name", mapped to the URL of a remote repo.
// Add a new "remote name" maps to the URL of a remote repo $ git remote add <remote-name> <remote-url> // For example, $ git remote add origin https://hostname/username/project-name.git // Define a new remote name "origin" mapping to the given URL // List all the remote names $ git remote -v // Delete a remote name $ git remote rm <remote-name> // Rename a remote name $ git remote rename <old-remote-name> <new-remote-name>
Cloning a Remote Repo (revision)
$ git clone <remote-url> // Init a GIT local repo and copy all objects from the remote repo $ git clone <remote-url> <working-directory-name> // Use the working-directory-name instead of default to project name
Whenever you clone a remote repo using command "git clone <remote-url>
", a remote name called "origin
" is automatically added and mapped to <remote-url>
.
[TODO] Diagram
Fetch/Merge Changes from remote (git fetch/merge)
The "git fetch
" command imports commits from a remote repo to your local repo, without updating your local working tree. This gives you a chance to review changes before updating (merging into) your working tree. The fetched objects are stored in remote branches, that are differentiated from the local branches.
$ cd /path-to/working-directory $ git fetch <remote-name> // Fetch ALL branches from the remote repo to your local repo $ git fetch <remote-name> <branch-name> // Fetch the specific branch from the remote repo to your local repo // List the local branches $ git branch * master devel // * indicates current branch // List the remote branches $ git branch -r origin/master origin/devel // You can checkout a remote branch to inspect the files/commits. // But this put you into "Detached HEAD" state, which prevent you // from updating the remote branch. // You can merge the fetched changes into local repo $ git checkout master // Switch to "master" branch of local repo $ git merge origin/master // Merge the fetched changes from stored remote branch to local
[TODO] Diagram
git pull
As a short hand, "git pull
" combines "git fetch
" and "git merge
" into one command, for convenience.
$ git pull <remote-name> // Fetch the remote's copy of the current branch and merge it // into the local repo immediately, i.e., update the working tree // Same as $ git fetch <remote-name> <current-branch-name> $ git merge <remote-name> <current-branch-name> $ git pull --rebase <remote-name> // linearize local changes after the remote branch.
The "git pull
" is an easy way to synchronize your local repo with origin's (or upstream) changes (for a specific branch).
[TODO] Diagram
Pushing to Remote Repo (revision)
The "git push <remote-name> <branch-name>
" is the counterpart of "git fetch
", which exports commits from local repo to remote repo.
$ git push <remote-name> <branch-name> // Push the specific branch of the local repo $ git push <remote-name> --all // Push all branches of the local repo $ git push <remote-name> --tag // Push all tags // "git push" does not push tags $ git push -u <remote-name> <branch-name> // Save the remote-name and branch-name as the // reference (or current) remote-name and branch-name. // Subsequent "git push" without argument will use these references.
[TODO] Diagram
"Fork" and "Pull Request"
"Fork" and "Pull Request" are features provided by GIT hosts (such as GitHub and BitBucket):
- Pushing "Fork" button to copy a project from an account (e.g., project maintainer) to your own personal account. [TODO] diagram
- Pushing "Pull Request" button to notify other developers (e.g., project maintainer or the entire project team) to review your changes. If accepted, the project maintainer can pull and apply the changes. A pull request shall provide the source's repo name, source's branch name, destination's repo name and destination's branch name.
Feature-Branch Workflow for Shared Repo
Feature-Branch workflow is more prevalent with small teams on private projects. Everyone in the team is granted push access to a single shared remote repository and feature (or topic) branches are used to isolate changes made by the team members.
The project maintainer starts the "master
" branch on the shared remote repo. All developers clone the "master
" branch into their local repos. Each developer starts a feature branch (e.g., "user1-featureX
") to work on a feature. Once completed (or even work-in-progress), he files a "pull request" to initiate a review for his feature. All developers can provide comments and suggestions. Once accepted, the project maintainer can then merge the feature branch into the "master
" branch.
The steps are:
- Mark, the project maintainer, starts the project by pushing to the shared remote repo's "
master
" branch. - Carol, a contributor, clones the project into her local repo, via:
// Carol: $ cd parent-directory-of-the-working-directory $ git clone https://hostname/path-to/project-name.git // Create a remote-name "origin" (default), branch "master" // on her local repo
- Carol starts a feature branch (says "
carol-feature
") under the "master
" branch to work on a new feature, via:// Carol: $ git checkout -b carol-feature master // Create a new branch "carol-feature" under "master" branch // and switch to the new branch // Edit/Stage/Commit/Push cycles on carol-feature branch $ git status $ git add <file> $ git commit -m <message> $ git push origin carol-feature // Repeat until done
- Carol completes the new feature. She files a "pull request" (by pushing the "pull request" button on the Git host) to notify the rest of the team members.
- Mark, the project maintainer, or anyone in the team, can comment on Carol's feature. Carol can re-work on the feature, if necessary, and pushes all subsequent commits under her feature branch.
- Once the feature is accepted, Mark, or anyone in the team (including Carol), performs a merge to apply the feature branch into the "
master
" branch:// Mark, or Anyone: $ git checkout master // Switch to the "master" branch of the local repo $ git pull origin master // Fetch and merge the latest changes on local's "master" branch, // if any (i.e., synchronize) $ git pull origin carol-feature // Fetch and merge carol-feature branch on local's "master" branch $ git push origin master // Update the shared remote repo
- Everyone can update their local repo, via:
// Everyone: $ git checkout master // Switch to the "master" branch of the local repo $ git pull origin master // Fetch and merge the latest changes on local "master" branch
[TODO] Diagram
Forking Workflow
In Forking workflow, Instead of using a common shared remote repo, each developer forks the project to his own personal account on the remote host. He then works on his feature (preferably in a feature branch). Once completed, he files a "pull request" to notify the maintainer to review his changes, and if accepted, merge the changes.
Forking workflow is applicable to developers working in small teams and to a third-party developer contributing to an open source project.
The steps are:
- Mark, the project maintainer, pushes the project from his local repo ("
master
" branch) to a remote Git host. He permits "read" access by contributors. - Carol, a contributor, gotos Mark's repo, forks the project (by pushing the fork button). "Forking" copies the project to Carol's own personal account on the same Git host.
- Carol then clones the project from her forked repo into her local repo, via:
// Carol: $ cd parent-directory-of-the-working-directory $ git clone https://hostname/carol/project-name.git // Create a remote name "origin" automatically // Copy the "master" branch
- When a fork is cloned, Git creates a remote-name called
origin
that points to the fork, not the original repo it was forked from. To keep track of the original repo, Carol creates a remote name called "upstream
" and pulls (fetches and merges) all new changes:// Carol: $ cd carol-local-repo-of-the-fork $ git remote add upstream https://hostname/mark/project-name.git // Create a remote-name "upstream" pointing to the original remote repo $ git remote -v // List all the remote names and URLs // origin: mapped to Carol's forked remote repo // upstream: mapped to Mark's original remote repo $ git pull upstream master // Fetch and merge all changes from the original remote repo to local repo // for the "master" branch
- Now, Carol can make changes on her local repo (on a new branch), stage and commit the changes, and pushes them to her forked remote repo (so called Edit/Stage/Commit/Push cycles):
// Carol: $ git checkout -b carol-feature master // Create a new branch called "carol-feature" under "master" // and switch to the new branch // Edit/Stage/Commit/Push cycles on "carol-feature" branch $ git status $ git add <file> $ git commit -m <message> $ git push origin carol-feature // Repeat until done
- Carol files a pull request to Mark (the project maintainer) by pushing the pull-request button. She needs to specify her forked remote repo-name, her branch name (
carol-feature
), Mark's remote repo-name, and Mark's branch name (master
). - Mark opens the pull request (in pull request tab), reviews the change, and decides whether to accept the changes. Mark can ask Carol to re-work on the feature. Carol repeats the Edit/Stage/Commit/Push cycles.
If Mark decides to accept the changes, he pushes the "Merge" button to merge Carol's contribution to hismaster
branch on the remote repo.
[If there is no "Merge" button] Mark needs to do the following:// Mark: $ git checkout master // Checkout the "master" branch of the local repo $ git remote add carol git://hostname/carol/project-name.git // Add a new remote pointing to the Carol's forked remote repo $ git pull carol carol-feature // Fetch and merge the changes into local repo's master branch $ git push origin master // Push the update to the Mark's original remote repo
- All contributors (including Mark and Carol) shall regularly synchronize their local repo by fetch/merge with Mark's
master
branch.// Carol (and everyone): $ git checkout master // Switch to the "master" branch of the local repo $ git pull upstream master // Fetch and merge the latest changes on "master" branch from // original remote repo to his local repo
Other Workflows
There are other workflows such as "Centralized Workflow" and "GitFlow Workflow". Read "https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow".Miscellaneous and How-To
Stage and Commit (git commit -a -m <message>)
You can skip the staging (i.e., the "git add <file>...
") and commit all changes in the working tree via "git commit -a -m <message>
" with -a
(or --all
) option.
Stage all changes (git add -A)
You can use "git add -A
" to stages all changes in the working tree to the staging area.
Unstage a Staged file (git rm --cached <file> / git reset head <file>)
Recall that you can use "git add <file>
" to stage new files or modified files into the staging area.
To unstage a staged new file, use "git rm --cached <file>
".
To unstage a staged modified file, use "git reset head <file>
".
Unmodified a modified file (git checkout -- <file>)
After a commit, you may have modified some files. You can discard the changes by checking out the last commit via "git checkout -- <file>
".
 // Stage $ git add ...... // Commit $ git commit -c ORIG_HEAD
The "git reset --hard HEAD~1
" moves the HEAD
to the previous commit, restore the working tree and discard the index (i.e., discard all change after the previous commit). Instead of HEAD~n
, you can also specify the commit hash code.
The "git rest HEAD~1
" with default --mixed
moves the HEAD
to the previous commit, keep the working tree and discard the index
The "git reset --soft HEAD~1
" moves the HEAD
to the previous commit, keep the working tree and the index (i.e., keep all changes after the previous commit).
[TODO] Examples, diagrams and "git status
" outputs.
For a public repo, you probably need to make another commit and push the commit to the public repo, or ...
Relative Commit Names
A commit is uniquely and absolutely named using a 160-bit (40-hex-digit) SHA-1 hash code of its contents. You can always refer to a commit via its hash value or abbreviated hash value (such as the first 7 hex-digit) if there is no ambiguity.
You can also refer to a commit relatively, e.g., master~1
(Windows), master^
(may not work in Windows), master^1
refers to the previous (parent) commit on the master
branch; master~2
, master^^
refers to the previous of the previous (grandparent) commit, and etc. If a commit has multiple parents (e.g., due to merging of branches), ^1
refers to the first parent, ^2
refers to the second parent, and so on.

- Git Hosts: GitHub @ https://github.com, Bitbucket @ https://bitbucket.org.
- Git Tutorials @ https://www.atlassian.com/git/tutorials.
- Bitbucket Documentation Home @ https://confluence.atlassian.com/display/BITBUCKET/Bitbucket+Documentation+Home.
- Bitbucket 101 @ https://confluence.atlassian.com/display/BITBUCKET/Bitbucket+101.
- Jon Loeliger and Matthew McCullough, "Version Control with Git", 2nd Eds, O'reilly, 2012.
- Scott Chacon, "Pro Git", Apress, 2009.


publications
My academic publications and research contributions
2021
- Duco: Autonomous Large-Scale Direct-Circuit-Writing (DCW) on Vertical Everyday Surfaces Using A Scalable Hanging PlotterProc. ACM Interact. Mob. Wearable Ubiquitous Technol. 2021
- MARS: Nano-Power Battery-Free Wireless Interfaces for Touch, Swipe and Speech InputIn The 34th Annual ACM Symposium on User Interface Software and Technology 2021
2020
- Ice Topography Reconstruction and Panoramic Stitching using Forward Looking Sonar ImagesIn Global Oceans 2020: Singapore – U.S. Gulf Coast 2020
2019
- Ocean-Glacier Interactions in the McMurdo Sound: Lessons for Deep Ice on Ocean Worlds?LPICo 2019
- Water Circulation and Microbial Diversity in Antarctic Ocean World Analog EnvironmentsIn 2019 Astrobiology Science Conference 2019
- Digital Holographic Microscopy for the Icefin Underwater Vehicle: Initial Progress and Future StepsIn 2019 Astrobiology Science Conference 2019
- In Situ Observations of the Erebus Glacier Tongue Grounding Zone by the Icefin HROV.In Geophysical Research Abstracts 2019
2018
- Wear-a-CUDA: a GPU based dolphin whistle recognizer for underwater wearable computersIn Proceedings of the 2018 ACM International Symposium on Wearable Computers 2018
- Modular Controls and Instrumentation Software for Icefin ROVIn OCEANS 2018 MTS/IEEE Charleston 2018
2017
- What’s Cooler Than Being Cool? Icefin: Robotic Exploration Beneath Antarctic Ice ShelvesAGUFM 2017


Source
Target
advanced settings
Advanced settings:
Algorithm:
tf-idf - scikit-learn
fuzzy
Weights:- Semantic:
Location:
Length:
Special tokens:
Settings:- Minimum semantic score:
Minimum length score:
Search range:
Align
...


Reports redundant operations on empty collections, maps or arrays. Iterating, removing elements, sorting,
and some other operations on empty collections have no effect and could be removed or signal about a possible bug.
Example:
if (numbers.isEmpty()){
//error due to the missed negation
int max = numbers.stream().max(Comparator.naturalOrder()).get();
...
}
New in 2019.1


Man who bit garda’s finger resulting in broken bone told suspended sentence “unduly lenient”
by By Ruaidhrí GiblinA man who bit a garda's finger with such force that he broke the bone is facing potential jail time after being told his suspended sentence was too lenient.
Brandon Power (21), of St Jospeh’s Road, Newtownmountkennedy, pleaded guilty to assaulting Garda Thomas Devereux in Bray courthouse on March 31, 2018.
The Court of Appeal heard that Power was being sentenced for another matter when he became aggrieved and attempted to flee. As he was being restrained, he bit down on the garda’s finger.
Gda Devereux told the court he had never felt pain like it and heard his own finger snap during the attack, thinking Power had bitten it off.
The accused was given a wholly suspended one year sentence by Judge Terence O’Sullivan on April 11, 2019, which was found “unduly lenient” by the Court of Appeal today/yesterday(FRIDAY).
Counsel for the Director of Public Prosecutions, James Kelly BL, submitted that there had to have been a “serious application of force” to break the finger.
President of the Court of Appeal Mr Justice George Birmingham said he was in "no doubt" that Power’s suspended sentence was “unduly lenient”.
He said Garda Devereaux was simply performing his duty, attempting to prevent Power’s escape from custody.
Mr Justice Birmingham said there were significant mitigating factors present including previous mental health difficulties, and powerful evidence from Power’s mother.
The court sought an up-to-date probation report, ahead of resentencing, and Power was allowed to remain on bail.
Mr Justice Birmingham, who sat with Mr Justice Patrick McCarthy and Ms Justice Isobel Kennedy, said the court was not to be taken as indicating that a custodial sentence was not going to be imposed.
The matter was put back to March 10 for resentencing.


This page contains webassembly and javascript content, please enable javascript in your browser.
Wasm Tangle
Loading WebAssembly...


A new review from the Appzine, a handy source of information for all tech enthusiasts.


In the JavaScript language, describe all the use cases for each of: parentheses () - e.g. '1. Execute a function var result = doSomething()' also to surround conditional statements. e.g if() { };
brackets [] Are mostly used for accessing the properties of an object or the element of an Array. e.g var myFruits = ['Mango', 'Banana', 'Apple']; alert myFruits[2]; will get the the third element in the Array.
braces {} Are used during the declaration of object literals. for eg. var myFruits = { Banana: 'Yellow', Apple: 'Red', } etc. it is also used to enclose the block of code like in function definations,conditional blocks, and loops etc. for eg. function --() = { }; then for the loop, for() { }; and if statements if () { };
single quotes '' we use single quotes when we are handling the strings in JavaScript. You'll want to use single quotes where you want double quotes to appear inside the string (e.g. for html attributes) without having to escape them, or vice versa. for eg. var myName = 'Mini';
double quotes "" You'll want to use single quotes where you want double quotes to appear inside the string (e.g. for html attributes) without having to escape them, or vice versa. var myCar = 'My car is "RED" ' console.log(myCar); My car is "RED"


Mr. Rice's Secret
not rated 92 minutes New City Distribution starring Bill Switzer, David Bowie, Garwin Stanford, and Zack Lipovsky written by J.H. Wyman directed by Nicholas Kendall
A Review by Frankie Paiva
David Bowie isn't exactly the person you would expect to be appearing in a family film. Even stranger is that he's in a film having to do with such serious material like death, fear of death, and growing up with Hodgkin's disease. The surprising secret is that Bowie is the best part of the movie. While given first billing, he's in no more than ten minutes of the picture, but his voice, messages, and spirit live on in the main character. That character is Owen Walters (Bill Switzer) a nearly friendless young boy with Hodgkin's disease. The two spend a lot of time together. Owen looks for support, care, and advice in Mr. Rice when his parents aren't providing it. I'd be running to this guy too. The parents (played by Teryl Rothery and Garwin Standford) apparently love their son very much. However, all these clueless two ever do is make their child's situation worse by not encouraging him or answering his questions. They are unawares to the feelings their child is experiencing.  Together these people could make quite a tedious tense family drama, and at many times they do. Helping things move along though is the pursuit of treasure. When Mr. Rice dies, he leaves behind a decoder ring and code so Owen can find his secret. Soon Owen is digging up dead bodies, breaking into houses, and discovering lost keys that could all lead to Mr. Rice's secret. It's quite plain what the secret is early on in the film, but the journey is exciting and I was waiting to see what Owen would do with it.
Despite some somewhat solid performances, particularly from its lead, there isn't a huge reason to see Mr. Rice's Secret. There isn’t a reason to see it with the kids either. This certainly isn't a family film, even though it's marketed as one. The themes of death will be too heavy and boring for most children and the film contains an awful lot of unneeded swearing and a very brief sexual image. The problem is simple. I counted at least ten noticeable clichés I had all seen in, at minimum, five other movies. Thinking back, it's hard to recall a part of Mr. Rice's Secret that seemed original, witty, or unique. Cliché ridden movies are not always bad, but the emotion exhibited by the actors is faker than Cher's body. Last year, October Sky managed to be entertaining and sad even though it too was cliché ridden. However, that movie had much better actors. This isn't to say director Nicholas Kendall doesn't pull some things off. One character has a very funny stuttering punk brother, and there is a great close-up shot of ants feeding on a rotten apple in one frightening scene. There is also a very funny discussion about how authority figures (like parents) are meant to get lied to. Even so, I doubt parents want their children learning that you can dig up graves in the middle of the night and get away with it. They probably wouldn't want kids to blackmail their siblings, or know you can always sneak out your bedroom window without ever getting caught either. Additionally, we must not forget the most important lesson of all.
I do appreciate the attempt to capture young boy's friendships and their true meaning, but this movie is just a depressing sham. The difficulties Owen must face never rise above the after-school special drama level, and when I figured out the ending about thirty minutes into the movie that didn't help either. I got continuously reminded of an Aesop fable the entire time, thinking that each scene was there to teach me a lesson, and they do. Perhaps the film will be an inspiration to children with Hodgkin's, leukemia, or other types of life threatening diseases. It shows that you can succeed, have friends, and triumph in life if you are only willing to try and prove yourself. The actors tried, and almost flourished. Mr. Rice's Secret isn't a guilty pleasure; it's more of a guilty emotional enjoyment. Even if I knew what was going to happen, I still left with a feeling of happiness. There just wasn't enough real emotion or material happening in the story to get this thing off its feet, or for me to rise up and cheer.
C-
Frankie Paiva<EMAIL_ADDRESS>http://www.homestead.com/cinemaparadise/mainpage.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Overview
There has been no roadmap published by the DTA. We sometimes hear through the media that an update may be coming, but we don't know what that update will contain until it is published, and then it is just the brief release notes on the app stores or we compare the decompiled app with the previous version. The only certain item that has been mentioned several times is that they are planning to integrate the Exposure Notification APIs developed by Apple and Google. But there has been no mention or discussion by the DTA on what this integration may involve.
If the @DTA were to update the #COVIDSafe app with the Google/Apple Exposure Notification APIs, it would require some hefty changes to a lot of things. A brief investigation.
— Steve Williams (@KonajuGames) May 7, 2020
cc. @GeoffreyHuntley


Installing various packages can make your system vulnerable to any known or discovered security issues in the software. Hackers trying to gain access to your machine often can take advantage of such security holes in your system's software. For this reason, it is highly recommended to purge anything on your machine that is not required to be there.
Netcat is a utility that allows the reading and writing of TCP and UDP packets. It can be used to create network backdoors in the system, and it should be removed. (When removing netcat, do check the system for any netcat backdoors)
To check if netcat is installed on your system, you can type dpkg -l | grep netcat. (the grep command is to find packages with names containing "netcat")
If results come up, then some version of netcat is likely installed. To remove apache, purge the results that return from the above command. (For example: sudo apt-get purge netcat netcat-traditional netcat-openbsd)
That should be it!


At times it becomes necessary to paginate content to break it into more understandable pieces.
This can be very easily achieved in Angular-Bootstrap via a single directive.


Step 2: Finding Information
Now that you’ve carefully made a list of the principles and goals you want out of your candidate,
you are ready to find evidence to select your him, or her, in the most unbiased manner possible.
Finding unbiased and unfiltered information may require some searching. Below are a few
suggestions to get you on the right track.
Speech/Debate Transcripts
The biggest strength in using a transcript is not having quotes
or statements taken out of context. A proper transcript should include the
entire text of what was said by the candidate(s) in the speech or debate.
In this way, you will get a better understanding of why the candidates made
the statements they did, and not only get an unfiltered view of their
principles, but the whole story as well.
If possible, find more than one transcript of a certain speech or debate.
Some media sources may leave certain segments or bits of information out to
better suit their narrative. By finding consistent information from more
than one source, you can be more confident that your findings reflect reality
and the truth.
Filmed Speeches/Debates
Upon reading a transcript, you may find that some of the responses or statements
might not make sense, or even be controversial. Having footage of the speech or
debate will help you understand the speaker’s tone, and context of the situation.
When searching for filmed speeches or debates, especially if you are opting to
not use transcripts, try to find complete, unedited versions of the event. Only
watching segments of the speech or debate will not give you complete context of
the situation, or provide you with reasoning for why certain discussions or
statements took place.
Lastly, make sure that the footage you are watching does not have a commentator.
The commentator may sway you towards a certain candidate using his or her own
bias. If you want your decision to be truly your own, you will need to remove
as many of these external influencing factors as possible.
Statements
Statements released by candidates tend to be well-articulated pieces of writing
on issues brought up during the election.
These statements are an easy way of
determining the stance of the candidate on certain issues, and how they will
accomplish them.
Similar to the previous headings, find the complete statements
which do exclude any sections. An incomplete statement may compromise the stance
they are trying to make, and the message they are trying to send you.
Use the list(s) you made in the first step to select your candidate based on the
unfiltered, unedited events.


--- title: Summer Camp Apparel layout: "default" published: false ---
Back to main Summer Camp page
2020 Summer Camp shirts are available online Monday, February 24 at 9AM for Garden Members / Wednesday, February 26 at 9AM to the General Public.
Summer Camp shirts are a fun way to get into the spirit of camp at Red Butte Garden. Wearing a Red Butte Garden shirt is optional, but if interested, camp t-shirts are available for purchase ($10) at the time of registration until May 13 at this link, and are available throughout the summer at the Visitors Center front desk.


I recently graduated from university Of Maryland with IS degree. I love getting things done
with great passion and determination. I am proud of my work in different places to give great
customer services.
Technical Skills
Virtual Cloud: google drive, Virtualization, VMware


Buttons........................................................................................................................................................................ 1
Buttons..................................................................................................................................................................... 1
Buttons..................................................................................................................................................................... 2
Button States and
Shapes...................................................................................................................................... 2
Button Tracking..................................................................................................................................................... 3
Events, State
Transitions and Actions................................................................................................................... 3
Button Records...................................................................................................................................................... 4
DefineButton......................................................................................................................................................... 5
DefineButton2....................................................................................................................................................... 6
DefineButtonCxform............................................................................................................................................. 7
DefineButtonSound............................................................................................................................................... 7
Macromedia Flash File Format (SWF) SDK
Examples................................................................... 7
Button objects are the key to interactivity in a Macromedia Flash movie. Buttons are the only objects that can react to events such as mouse movement and mouse clicks. When an event occurs, the button object can perform a series of actions, such as jumping to a URL or jumping to another frame in the movie. This event-action model is surprisingly powerful. Button objects have been used to serve many purposes, from simple menus, to sprites in a complex game.
A button object can be displayed in one of three states: up, over, or down.
The up state is the default appearance of the button. The up state is displayed when the Macromedia Flash movie starts playing, and whenever the mouse is outside the button. The over state is displayed when the mouse is moved inside the button. This allows ‘rollover’ or ‘hover’ buttons in a Macromedia Flash movie. The down state is the ‘clicked’ appearance of the button. It is displayed when the mouse is clicked inside the button.
A fourth state – the hit-state – defines
the active area of the button. This is an invisible state and is never
displayed. It defines the area of the
button that reacts to mouse-clicks.
Each state is defined by a BUTTONRECORD. The button record contains a link to a previously defined shape, called a character. For visible states, this shape is rendered to the display when the button enters the state. For the hit-area, this shape defines the active area of the button.
Below is a typical button and its four states.
The button is initially blue.
When the mouse is moved over the button it changes to a mauve
color. When the mouse is pressed inside
the button, the shading changes to simulate a depressed button. The fourth state – the hit-area – is a
simple rectangle. Anything outside this
shape is outside the button, and anything inside this shape is inside the
button.
Here is an overview of the button states:
·
The Up State — The
default appearance of the button.
This shape defines what the button looks like when the
button is ‘idle’. That is, when the
cursor is outside the hit-area. A button is always in the up state when the
movie starts playing.
·
The Over State — The
mouse-over state.
This shape defines what the button looks like when the
cursor is ‘over’ the button. That is,
when the cursor is inside the hit-area. The
over state can be used to create ‘rollover’ or ‘hover’ buttons in a Flash
movie.
·
The Down State — The
‘clicked’ appearance of the button.
This shape defines what the button looks like when the
mouse button is pressed while the cursor is inside the hit-area.
·
The Hit Area — The
active area of the button.
This shape is never displayed; it defines the active area
of the button that reacts to events such as mouse-clicks. The hit-area is not necessarily rectangular
and need not reflect the visible shape of the button.
Macromedia Flash (SWF) has no native support for radio-buttons or checkboxes. There is no ‘checked’ state, and buttons cannot ‘stick’ down after the mouse is released. Neither is there any way to group buttons into mutually exclusive choices. However, both these behaviors can be simulated using button actions.
Button tracking refers to how a button behaves as it ‘tracks’ the movement of the mouse. A button object can track the mouse in one of two modes:
1.
As a push button
2.
As a menu button.
If a push button is clicked, all mouse movement events are directed to the push button until the mouse button is released. This is called ‘capturing’ the mouse. For example, if you click a push button and drag outside the button (without releasing) the button changes to the over state, and the pointer remains a hand cursor.
Menu buttons do not capture the mouse. If you click on a menu button and drag outside, the button changes to the up state, and the pointer reverts to an arrow cursor.
A button object can perform an action whenever there is a state transition, that is, when the button changes from one state to another. A state transition occurs in response to some event, such as a mouse-click, or mouse entering the button.
The Macromedia Flash user-interface and Macromedia Flash (SWF) use different terminology to describe how button actions are triggered. In the Macromedia Flash user-interface, button actions are performed in response to events. In Macromedia Flash (SWF), button actions are performed in response to state transitions. For the purposes of this discussion, events and state transitions are equivalent.
Below is a table of possible state transitions and corresponding Macromedia Flash events:
|
State Transition |
Flash Event |
Description |
Visual Effect |
|
IdleToOverUp |
Roll Over |
Mouse enters the
hit area while the mouse button is up. |
Button changes from
up to over state. |
|
OverUpToIdle |
Roll Out |
Mouse leaves the
hit area while the mouse button is up. |
Button changes from
over to up state. |
|
OverUpToOverDown |
Press |
Mouse button is
pressed while the mouse is inside the hit area. |
Button changes from
over to down state. |
|
OverDownToOverUp |
Release |
Mouse button is
released while the mouse is inside the hit area. |
Button changes from
down to over state. |
These transitions only apply when tracking Push buttons:
|
State Transition |
Flash Event |
Description |
Visual Effect |
|
OutDownToOverDown |
Drag Over |
Mouse is dragged
inside the hit area while the mouse button is down. |
Button changes from over to down state. |
|
OverDownToOutDown |
Drag Out |
Mouse is dragged
outside the hit area while the mouse button is down. |
Button changes from down to over state. |
|
OutDownToIdle |
Release Outside |
Mouse button is released outside the hit area
while the mouse is captured. |
Button changes from over to up state. |
These transitions only apply when tracking Menu buttons:
|
State Transition |
Flash Event |
Description |
Visual Effect |
|
IdleToOverDown |
Drag Over |
Mouse is dragged
inside the hit area while the mouse button is down. |
Button changes from up to down state. |
|
OverDownToIdle |
Drag Out |
Mouse is dragged
outside the hit area while the mouse button is down. |
Button changes from down to up state. |
Typically button actions are performed on OverDownToOverUp (when the mouse button is released), but DefineButton2 allows actions to be triggered by any state transition.
A button object can perform any action supported by the DoAction flag.
A button record defines the shape to be displayed for a button state. The ButtonState flags indicate which state (or states) the shape belongs to.
There is not a one-to-one relationship between button records and button states. A single button record may define more than one button state (by setting multiple ButtonState flags), and two or more button records may refer to the same button state. In this case, both shapes will be displayed for that state.
Each button record also includes a transformation matrix and stacking-order information.
(See class FAButtonRecord in the Macromedia Flash File Format (SWF) SDK)
|
BUTTONRECORD |
||
|
Field |
Type |
Comment |
|
ButtonReserved |
UB[4] |
Reserved bits – always 0 |
|
ButtonStateHitTest |
UB[1] |
Button state hit test flag |
|
ButtonStateDown |
UB[1] |
Button state down flag |
|
ButtonStateOver |
UB[1] |
Button state over flag |
|
ButtonStateUp |
UB[1] |
Button state up flag |
|
ButtonCharacter |
UI16 |
Button character ID |
|
ButtonLayer |
UI16 |
Button character layer |
|
ButtonMatrix |
Button character matrix |
|
|
ColorTransform |
Character color transform |
This tag defines a button character for later use by control tags such as PlaceObject.
DefineButton includes an array of BUTTONRECORDs which represent the four button shapes – an up character, a mouse-over character, a down character, and a hit-area character. It is not necessary to define all four states, but there must be at least one button record. For example, if the same button record defines both the up and over states, only three button records are required to describe the button.
More than one button-record per state is allowed. If two button records refer to the same state, both shapes will be displayed for that state.
DefineButton also includes an array of ACTIONRECORDs which are performed when the button is clicked and released. See the DoAction tag. (SWF 1.0)
(See class FDTDefineButton in the Macromedia Flash File Format (SWF) SDK)
|
Define Button |
|
|
|
Field |
Type |
Comment |
|
Header |
RECORDHEADER |
Tag ID = 7 |
|
ButtonId |
UI16 |
ID for this character |
|
Buttons |
BUTTONRECORD[one
or more] |
Button character records |
|
ButtonEndFlag |
UI8 = 0 |
Always set to 0 |
|
Actions |
ACTIONRECORD[zero or more] |
Actions to perform - see
below |
|
ActionEndFlag |
UI8 = 0 |
Always set to 0 |
DefineButton2 extends the capabilities of DefineButton by allowing actions to be triggered by any state transition.
(See class FDTDefineButton2 in the Macromedia Flash File Format (SWF) SDK)
|
DefineButton2 |
||
|
Field |
Type |
Comment |
|
Header |
RECORDHEADER |
Tag ID = 34 |
|
ButtonId |
UI16 |
ID for this character |
|
Flags |
UI8 =0 or 1 |
Track as menu flag |
|
Offset |
UI16 |
Offset to the first Button2ActionCondition (immediately following the
BUTTONRECORDs) |
|
Buttons |
BUTTONRECORD[one or more] |
Button character records
with color transform with alpha |
|
ButtonEndFlag |
UI8 = 0 |
Always set to 0 |
|
Button2ActionCondition |
|
Specifies a series of
actions to perform based on a condition. Each Button2ActionCondition consists
of ActionOffset, Condition, Actions, and ActionEndFlag |
|
ActionOffset |
UI16 |
Points to next
Button2Action condition |
|
Condition |
UI16 |
Button state transitions
triggering an action. |
|
Actions |
ACTIONRECORD[zero or more] |
Actions to perform – see
the DoAction tag |
|
ActionEndFlag |
UI8 = 0 |
Always set to 0 |
Note: The ActionOffset preceding the last
Button2ActionCondition should be zero.
Defines the color transform for each shape and text character in a button. Not used for DefineButton2. (SWF 2.0)
(See class FDTButtonCxform in the Flash File Format SDK)
|
Define Button Cxform |
||
|
Field |
Type |
Comment |
|
Header |
RECORDHEADER |
Tag ID = 23 |
|
ButtonId |
UI16 |
Button ID for this
information |
|
ButtonColorTransform |
Character color transform |
The DefineButtonSound tag defines which sounds (if any) are played on state transitions. (Macromedia Flash (SWF) 2)
(See class FDTButtonButtonSound in the Macromedia Flash File Format (SWF) SDK)
|
DefineButtonSound |
||
|
Field |
Type |
Comment |
|
Header |
RECORDHEADER |
Tag ID = 17 |
|
ButtonId |
UI16 |
The ID of the button these
sounds apply to. |
|
ButtonSoundChar0 |
UI16 |
Sound ID for OverUpToIdle |
|
ButtonSoundInfo0 |
Sound style for
OverUpToIdle |
|
|
ButtonSoundChar1 |
UI16 |
Sound ID for IdleToOverUp |
|
ButtonSoundInfo1 |
Sound style for IdleToOverUp |
|
|
ButtonSoundChar2 |
UI16 |
Sound ID for
OverUpToOverDown |
|
ButtonSoundInfo2 |
Sound style for
OverUpToOverDown |
|
|
ButtonSoundChar3 |
UI16 |
Sound ID for
OverDownToOverUp |
|
ButtonSoundInfo3 |
Sound style for OverDownToOverUp |
The Macromedia Flash File Format (SWF) SDK contains C++ examples that demonstrate how to create buttons in Macromedia Flash (SWF):
· FExampleButton.cpp uses the low-level manager to create four rectangular shapes from straight edge records. The rectangles are assigned to button records, and added to the button as the up, over, down and hit states. An OverDownToOverUp condition is added, which performs a ‘Play’ action.
· HFExampleButton.cpp uses the high-level manager to define four rectangle objects, which become the up, down, over and hit states of a high-level HFButton object. Two event/action pairs are added to the button’s event queue. They are GetURL and Play actions, which are both performed on the ‘RELEASE’ event. That is, when the mouse button is released inside the button.


FUTURE WORKS... (or murmurs)
Tried But Failed Things
- parameterization of stack
- Like
Allocator::rebind
, I could realize it, but it was regarded as lack of simplicity. - It is no delight to parameterize stack...
Easy Things To Do
- Perpetuation of Parser
- I cannot imagine the usage of it, but I can do it.
- Grammar / Visualization of Table / XML-nization
- Basically it's a variation of generator.
- I think it seems to be ended by throwing into boost.graph and outputing by graphviz etc.
Difficult Things To Do
- GLR parser
- Now might be the GLR parser age...( implemented by Elkhound, D Parser, bison-derived etc. )
- There seems to have difficult problems to solve.
- EBNF
- Not so difficult to do, ...
- There are problems on start up of semantic action... (I don't know how to treat lists...)
- Like this?
struct SemanticActin { int DoAction1( const parser::Sequence< T >& s ){} int DoAction2( const parser::Optional< T >& s ){} }
- That I think so ... I cannot treat
(Foo Bar Baz)*
-like grammars. - Scannar-Less Parser
- Usability is very good, but that has demerits...
- If scanner-less, token will be char.
- RegExp-to-Caper grammar converter required?
- Is it easy if I can use
boost::variant
in output parser? - Is the table likely to be huge?
- Are there much separate merits?...
- I hope
boost::regex
had match actions or like that. - The current
boost::regex
cannot determine which pattern was matched in O(1), so that is not suitable for scanner. - Can I realize it by converting to token numbers by
replace_match
or like so? - Is it OK that the scanner only uses spirit?
- Is it all right by
boost::tokenizer
? - Auto generation of AST
-
boost::variant
was very good rather than I think. - It seems that AST auto generation by using
boost::variant
may be realizeable. - ... I think so, but it is not so easy, isn't it?
Things To Improve
- Dynamic parser engine
- The interface is not so good. I want to fix the bugs.
Miscellaneous
Your opinions and bug reports are wanted about...
- What compiler with what options causes what warnings.
- This part of the source should use what of Boost.
- I can make it clean and/or improve extendability.
- I want to do something but I cannot. Can you help me?
- I cannot understand the meaning of this error message.
- This error message is wrong in English
- This component name is not intuitive.
Don't hesitate to email me. Anonymous OK.


[BF4][v1.3][12.12.2013] My plugin name
[BF3/BF4][v1.0 beta][12.12.2013] My plugin name
2. Add a changelog to the first post with the spoiler tag.
3. Maybe add some screenshots for the customers.
4. Always add a link to the non minified version of your script - When your plugin is in the gallery than you can add just the JS link of your plugin
5. If the plugin is outdated or not in development anymore, add a [INACTIVE] to the topic title.
6. Don't post malware, spy or other bad plugins.
Plugin Gallery Rules
1. Always upload a non minified version of your plugin. Minified versions obfuscate and block people from helping you.
2. Plugins in the plugin gallery must be very well tested on all available browsers.
3. If your plugin stop working because of a battlelog update than deactivate it until all bugs are fixed. Inactive plugins doesn't show up in the gallery or in BBLog.
4. Always add a clear and short description what your plugin exactly does
5. If the plugin is outdated or not in development anymore, set it to inactive.


<prodinfo>
The <prodinfo>
metadata element contains information about the product
or products that are the subject matter of the current topic. The
<prodinfo>
element may be used to provide a more detailed definition
of values used throughout the map or topic on the @product
attribute.
Category: Prolog (metadata) elements


- setAt(AffineTransform) - Method in class model.paint.strategies.ShapePaintStrategy
-
Set the affine transform for the paint strategy.
- setColor(Color) - Method in class model.balls.Ball
-
Setter for the color.
- SetColorStrategy - Class in model.strategies
-
- SetColorStrategy() - Constructor for class model.strategies.SetColorStrategy
-
- SetDispatcherSequential<TDispMsg> - Class in util
-
- SetDispatcherSequential() - Constructor for class util.SetDispatcherSequential
-
- setInteractStrat(IInteractionStrategy) - Method in class model.balls.Ball
-
- setRadius(int) - Method in class model.balls.Ball
-
The setter for the radius.
- setShape(Shape) - Method in class model.paint.strategies.ShapePaintStrategy
-
Set the shape of the paint strategy.
- setStrategy(IUpdateStrategy<IBallCmd>) - Method in class model.balls.Ball
-
The setter for the strategy.
- setStrategy(IUpdateStrategy<TDispMsg>) - Method in class model.strategies.SwitcherStrategy
-
Setter for the strategy.
- setVel(int, int) - Method in class model.balls.Ball
-
Setter for the velocity.
- ShakeStrategy<TDispMsg> - Class in model.strategies
-
A concrete strategy that makes the ball moves in a shaking pattern.
- ShakeStrategy() - Constructor for class model.strategies.ShakeStrategy
-
- ShapePaintStrategy - Class in model.paint.strategies
-
Concrete class that defines invariant painting behaviors to paint Shape objects for all its subclasses.
- SineMaker - Class in util
-
A utility class that can be used to create smoothly varying sinusoidal
numerical data.
- SineMaker(double, double, double) - Constructor for class util.SineMaker
-
The constructor takes several values to control the object's behavior.
- singleton - Static variable in class model.paint.shapes.EllipseShapeFac
-
A static field for easy reference.
- singleton - Static variable in class model.paint.shapes.RectangleShapeFac
-
the singleton
- singleton - Static variable in class util.Randomizer
-
the singleton
- SquarePaintStrategy - Class in model.paint.strategies
-
Paint strategy that paints a filled square with the Ball's radius.
- SquarePaintStrategy() - Constructor for class model.paint.strategies.SquarePaintStrategy
-
- start() - Method in class controller.Controller
-
Start the system
- start() - Method in class model.BallModel
-
start the timer
- start() - Method in class view.BallWorldMainAppFrame
-
Make the frame visible
- StraightStrategy<TDispMsg> - Class in model.strategies
-
A concrete strategy that makes the ball moves in a straight line.
- StraightStrategy() - Constructor for class model.strategies.StraightStrategy
-
- SwimFishPaintStrategy - Class in model.paint.strategies
-
Subclass of AnimatePaintStrategy that alternates between a Fish1PaintStrategy and a Fish2PaintStrategy.
- SwimFishPaintStrategy() - Constructor for class model.paint.strategies.SwimFishPaintStrategy
-
No-parameter constructor that instantiates an AffineTransform for internal use.
- SwimFishPaintStrategy(APaintStrategy, APaintStrategy, APaintStrategy, APaintStrategy) - Constructor for class model.paint.strategies.SwimFishPaintStrategy
-
Constructor that take in several fish paint strategy to make a swimming fish.
- SwitcherStrategy<TDispMsg> - Class in model.strategies
-
A decorator that encapsulate another strategy, which enables the strategy to be changed
at run time.
- SwitcherStrategy() - Constructor for class model.strategies.SwitcherStrategy
-
- switchStrategy(TDropListItem1) - Method in interface model.IModelCtrlAdpt
-
Switch the strategy of the switcher balls with the selected item.
- switchSwitcherStrategy(IUpdateStrategy<IBallCmd>) - Method in class model.BallModel
-
A method to switch the strategy of all existing switcher balls.


This module is contained in the modules/mod_example.c
file, and
is not compiled in by default. It illustrates many of
the aspects of the
Apache 1.2 API
and, when used, demonstrates the manner in which module callbacks are
triggered by the server.
The files in the src/modules/example directory
under the
Apache distribution directory tree are provided as an example to those
that wish to write modules that use the Apache API.
The main file is mod_example.c
, which illustrates all
the different callback mechanisms and call syntaxes. By no means does
an add-on module need to include routines for all of the callbacks -
quite the contrary!
The example module is an actual working module. If you link it into your server, enable the "example-handler" handler for a location, and then browse to that location, you will see a display of some of the tracing the example module did as the various callbacks were made.
To include the example module in your server, follow the steps below:
src/Configuration
file. If there isn't one, add
it; it should look like this:
AddModule modules/example/mod_example.o
src/Configure
script
("cd src; ./Configure"). This will
build the Makefile for the server itself, and update the
src/modules/Makefile
for any additional modules you
have requested from beneath that subdirectory.
src
directory).
To add another module of your own:
To activate the example module, include a block similar to the following in your srm.conf file:
<Location /example-info> SetHandler example-handler </Location>
As an alternative, you can put the following into a .htaccess file and then request the file "test.example" from that location:
AddHandler example-handler .example
After reloading/restarting your server, you should be able to browse to this location and see the brief display mentioned earlier.
Syntax: Example
Default: None
Context: server config, virtual host, directory,
.htaccess
Override: Options
Status: Extension
Module: mod_example
Compatibility: Example is only
available in Apache 1.2 and later.
The Example directive activates the example module's content handler for a particular location or file type. It takes no arguments. If you browse to an URL to which the example content-handler applies, you will get a display of the routines within the module and how and in what order they were called to service the document request.