Checkout subdirectory in git for previous revision

From: http://stackoverflow.com/questions/5859943/subdirectories-in-checked-out-directory-of-a-previous-revision-not-disappearing

To checkout a sub-folder from a previous revision, what you do is three commands:

git reset <hash> thing/
git checkout <hash> thing/
git clean -fd thing/

To revert back to the HEAD state:

git reset HEAD thing/
git checkout HEAD thing/
git clean -fd thing/

I didn't try the three HEAD commands above. But should work.

Adding deleted files in git

When you type:

git commit -a

Git will add the new, modified and deleted files automatically and commit them

However, there are cases when you want to 'git add' deleted files (that got deleted in your working directory).

I tried:

git add *

But this didn't workout. It only added the modified and created files.

I wanted a way to add the deleted files, I thought of issuing a 'git rm' command:

git rm *

BUT WAIT. THIS WILL DELETE EVERYTHING.

So, what is the solution.

The solution is to use:

git add -u

The -u (show for --update) tells git to compare to the tracked files in git rather than the working directory.

According to the GIT manual:

'git add' man page says about the -u option...

-u

--update

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

If no <filepattern> is given, default to "."; in other words, update all tracked files in the current directory and its subdirectories.

.gitignore by example

A git ignore is a file named ".gitignore" that gets placed in the top level directory of your git workspace.

It informs git to ignore files when adding and committing files.

# Exclude files with an extension
*.jar
*.o
*.a


# Do not exclude required.jar
!required.jar


# ignore the file TODO at the top level directory only
# thus /TODO will be ignored, but src/TODO will not be ignore.
/TODO


# To indicate a directory for ignoring it should end with a "/"


# This line ignores all directories and subdirectories named log/
log/


# This line only ignores the top level directory named build
/build/


# This ignores all files ending with txt inside doc/ directory, but not inside doc/example/
doc/*.txt

Important notes:
1. Files starting with / (slash) mean that you should start from the top level directory
2. The * (star) in doc/*.txt does not mean it will match any directories inside. It will only match top level files inside the doc directory ending with *.txt. Thus doc/example/test.txt will not be matched.

Tracking an /etc directory using GIT version control while preserving file permissions

.. while preserving permissions on the linux file system.

Here's how to do it:
1. Download the post hook file setgitperms from here or directly from here http://repo.or.cz/w/git.git/blob_plain/HEAD:/contrib/hooks/setgitperms.perl

2. Place the script inside your .git/hooks directory. You have two options here:

(Option A) To apply this for all git repositories newly created
Copy the file setgitperms.perl inside the directory:

mv setgitperms.perl /usr/share/git-core/templates/hooks/.

(Option B) To apply this hook for a specific directory only
Copy the file setgitperms.perl inside the directory:
mv setgitperms.perl <Your Project Directory>/.git/hooks/.

3. Although git new releases handles this, just to be safe, make sure to add execute permissions for the hook:
chmod +x setgitperms.perl

4. Inside the hooks directory, create a file named "pre-commit" and place in it the following lines:

#!/bin/sh

SUBDIRECTORY_OK=1 . git-sh-setup

$GIT_DIR/hooks/setgitperms.perl -r

5. Create file named post-merge and post-checkout and place the following content inside each:

#!/bin/sh

SUBDIRECTORY_OK=1 . git-sh-setup

$GIT_DIR/hooks/setgitperms.perl -w

6. Save the files and make sure they are executable using chmod +x:
chmod +x post-merge
chmod +x post-checkout
chmod +x pre-commit

7. Thats it.

Reference: http://serverfault.com/questions/5410/using-revision-control-for-server-configuration-files

Installing GIT on Linux Redhat or CentOS 5

First is first:

wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
rpm -Uvh epel-release-5-4.noarch.rpm
yum install git

Next steps, configure git configuraiton:

git config --global user.name "Basil Abbas"
git config --global user.email "basil@isu.net.sa"
git config --global color.ui auto

Creating a bare repository on a remote server:

mkdir project_directory
cd project_directory
git init --bare

Cloning the bare remote repository on a development machine:

cd /home/babbas
git clone ssh://hostname/path/to/project_directory

The best "git log" command to use

This is the best git log command to use:
git log --decorate --graph --oneline

You can alias this command as follows:
git config --global alias.lol "log --graph --decorate --oneline"

Now you can use it as follows:
git lol

Making two branches identical after a git merge

I had two branches, heavy_refactoring and master branch in git.
I have already merged heavy_refactoring into master, but I had some trouble since master looks different than heavy_refactoring at the end due to some changes that took place on master before the merge. These changes I dont want.

What I wanted is that the 'master' branch look exactly like heavy_refactoring.

So here are the steps:

1. Go to the master branch first.

git checkout master

2. First you do a git diff between the two branches:

git diff --summary master heavy_refactoring

This will shows us the differences that should take place for master to become heavy_refactoring. It is very important that you type 'master' before 'heavy_refactoring' to advise the git diffing to give the differences so that I can get from master to heavy_refactoring.

The --summary is a switch to tell the diff not to show the contents inside each file.

3. After running the command, a list of deleted, modified and created files show up.

4. If the diff tells you that I file is "deleted", this means it should be removed from the master branch using:

git rm file_to_remove

5. If the diff tells you that I file is "created", this means you have to copy it from the heavy_refactoring branch to the master branch using:

# Copying a file from another branch to the current branch
git checkout heavy_refactoring src/main/java/com/basil/TargetFile.java

6. If the diff tells you that I file got "modified", this means you also have to copy it from heavy_refactoring branch to the master branch. Notice that my objective here is to make master exactly like heavy_refactoring.

git checkout heavy_refactoring srcmain/java/com/basil/TargetFile2.java

At the end, I can run the git diff again and it will show me an empty result which will indicate that the two branches are exact:

git diff --summary master heavy_refactoring