Git squash all commits into a single commit

$ git rebase -i 

Remember again that this is a rebasing command. Don’t include any commit you’ve already pushed to a central server — doing so will confuse other developers by providing an alternate version of the same change.

Running this command gives you a list of commits in your text editor that looks something like this:

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

# Rebase 710f0f8..a5f4a0d onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

It’s important to note that these commits are listed in the opposite order than you normally see them using the log command. If you run a log, you see something like this:

$ git log --pretty=format:"%h %s" HEAD~3..HEAD
a5f4a0d added cat-file
310154e updated README formatting and added blame
f7f3f6d changed my name a bit

Notice the reverse order. The interactive rebase gives you a script that it’s going to run. It will start at the commit you specify on the command line and replay the changes introduced in each of these commits from top to bottom. It lists the oldest at the top, rather than the newest, because that’s the first one it will replay.

It’s also possible to take a series of commits and squash them down into a single commit with the interactive rebasing tool. The script puts helpful instructions in the rebase message:

#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

If, instead of "pick" or "edit", you specify "squash", Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:

pick f7f3f6d changed my name a bit
squash 310154e updated README formatting and added blame
squash a5f4a0d added cat-file

When you save and exit the editor, Git applies all three changes and then puts you back into the editor to merge the three commit messages:

# This is a combination of 3 commits.
# The first commit's message is:
changed my name a bit

# This is the 2nd commit message:

updated README formatting and added blame

# This is the 3rd commit message:

added cat-file

When you save that, you have a single commit that introduces the changes of all three previous commits.

Ref: http://git-scm.com/book/en/Git-Tools-Rewriting-History

Cherry-Picking specific commits from one branch to another

Say, for example you are working with two different branches. Dev-4.0 and Dev-5.0.

And you have made few changes/fixes in Dev-4.0 branch and now you want to bring those changes in to the Dev-5.0 branch.

GIT provides cherry-pick command to do that.

1. Go to Dev-4.0 branch and identify the commit id's which need to be cherry-picked.
ex: Below the commit id's for my changes in Dev-4.0 branch.
 8ae534e23d82070cdaaea4913415678affdab44b

892aec46126320b8a2e030b0017611509a57a7b

2. Go to Dev-5.0 branch and fire the following command.

> git cherry-pick  8ae534e23d82070cdaaea4913415678affdab44b

this will bring all your commit changes from Dev-4.0 to  Dev-5.0

If you have any conflicts during this time.
- Resolve the conflicting files
- Once you have resolved the issues, add them to git if it's not added.
- Commit the modified files.

Otherwise git automatically commit your changes with cherry-pick command itself, if there are no conflicts occurred.

Ref: http://gitref.org/inspect/

Now..hope you are good to go!!.

Checking user specific commits in GIT

> To filter your commit history to only the ones done by a specific author.

           git log --author=kondal.kolipaka@kony.com

 > -[number] option, which will limit the results to the last [number] commits.

         git log --author=kondal.kolipaka@kony.com  -4

> git log --since --before filter commits by date committed

If you want to specify a date range that you're interested in filtering your commits down to, you can use a number of options - I use --since and --before, but you can also use --until and --after. For example, if I wanted to see all the commits in the Git project before 3 weeks ago but after April 18th, I could run this (I'm also going to use --no-merges to remove merge commits):

     git log --oneline --before={3.weeks.ago} --after={2012-11-18} --no-merges

> git log --grep filter commits by commit message
You may also want to look for commits with a certain phrase in the commit message. You can use --grep for that. Let's say I knew there was a commit that dealt with using the P4EDITOR environment variable and I wanted to remember what that change looked like - I could find the commit with --grep.

    git log --grep=P4EDITOR --no-merges

Tooltip on tree viewer items

This describes about how to add a tooltip on tree viewer items based on the context of object. 

ExplorerViewer.getTree().addMouseTrackListener(new ExplorerMouseListener());

private class ExplorerMouseListener implements MouseTrackListener {

@Override

public void mouseEnter(MouseEvent e) {

}

@Override

public void mouseExit(MouseEvent e) {

}

@Override

public void mouseHover(MouseEvent event) {

TreeItem item = explorerViewer.getTree().getItem(new Point(event.x, event.y));

if (item != null && item.getData() instanceof MyResource) {

MyResource selectedElement = (MyResource) item.getData();

if (selectedElement.getResourceType() == MyResourceType.APP_GROUP

|| selectedElement.getResourceType() == MyResourceType.DATA) {

if (selectedElement.getData() instanceof INameDescription)

explorerViewer.getTree().setToolTipText(

((INameDescription) selectedElement.getData())

.getDescription());

} else {

explorerViewer.getTree().setToolTipText(null);

}

}

}

}

Template for git commit messages

Good commit messages always makes a difference!!!

Following is the template I generally refer to.


FEATURE/BUGFIX/ENHANCEMENT: KonyOne Studio - <Module name> - <short problem/module description>

<Detailed description of feature/solution description/enhancement comments>

<Fix: #JSP1234>

Reviewed By :  <reviewer name>


Example for Feature:

FEATURE: KonyOne Studio - Sky Data Explorer - Implemented model classes for sky explorer

Provided the offline support capabilities to work offline.

Reviewed by: Rakesh 


Example for BugFix:

BUGFIX: KonyOne Studio - Java Script Module - Heap memory issues with huge number of files.

Java script listener is modified..etc,..

Fix: #JSP12345


Example for Enhancement:

ENHANCEMENT: KonyOne Studio - Java Script Module - code clean for java script model

Unnecessary code has been removed in java script module.

Reviewed by: Rakesh 


Points to be considered:

• Topic description (first line)
•  72 characters max for each line.
•  Give space for title and body
•  Use present tense.(Generally git uses the same for merge/rebase)

Why 72 characters ??
git log doesn’t do any special special wrapping of the commit messages. 

On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns.


Good commit messages serve at least three important purposes:

• To speed up the reviewing process.
• To help us write a good release note.
• To help the future maintainers (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.

Eclipse OSGI framework

Hello...

I have found very interesting links which explains about OSGI framework.

Basic understaing on OSGI
http://www.vogella.com/articles/OSGi/article.html

Very very interesting article on Eclipse open source architecture
http://www.aosabook.org/en/eclipse.html

Discard unstaged changes in GIT

You might have lot of unstaged files, which you dont want to submit to GIT. You can use CHECKOUT option from the git to do this.

1. Removing a single file
   >git checkout <filename>

2. Removing all unstaged files.
  >git checkout reset --hard

3. Sometimes, option (2) does not work. you can use the following option.
  > git checkout -- .

Make sure to include the period at the end of command.