Hi Shalin,
As I mentioned in git comments, your commits include a bunch of generated binary files that are not supposed to be in the repository.
I don't usually get involved with OI Flashlight, but I did just copy the .gitignore file from OI Shopping List so that the generated files will be ignored going forward.
Now you just have to redo your commits to include only the files you want. It should be relatively straightforward. Here's one approach, which will perhaps unfortunately fold all your changes into a single commit.
First you need to make sure you have a git remote for the official OI repo. If you don't already, you can add it like this:
git remote add upstream g...@github.com:openintents/flashlight.git
Then fetch the latest changes from upstream:
git fetch upstream
Now, to roll back your commits in your local repository, but leave your code changes intact in your working tree:
git reset 2b7102db831eb7e17fd2fb5a6f84e74d1abcdf41
Now add the gitignore file:
git merge upstream/master
If there were conflicts between the latest changes on master and your working tree, you would have to merge them at this point... but that won't be an issue in this case unless you have added your own .gitignore file.
From here, your repo is in sync with upstream, and you have changes to commit. It's a good idea to use "git status" to see what files git thinks you have changed, and use "git add" to add only the files you want to commit. You can also use "gitk" or "git diff" to see the changes in your working tree vs the repository. One thing to watch out for is to avoid making whitespace / formatting changes in the same commit as real code changes, because that makes life difficult for reviewers by obscuring your real code changes. After you "git add" everything you want to commit, use "git commit" and add a commit message that describes the specific goals of the commit. For example "Add widget" or "New features" (ideally with an outline of the new features" would be good commit messages, while just saying "changes" or "modified foo.java" don't really add value.
It's good practice to review your commit in gitk before pushing to github, or at least to review what it looks like on github before posting to the developer list asking for review. Try to think like a reviewer and find things that could be done more cleanly, and if you do find them, you can always redo the commit before showing your code to everyone.
Once you are happy with the way the commit looks, post again here. The code is primary, so a link to a specific commit or branch that you want reviewed is critical... but it doesn't hurt to add an apk attachment to facilitate testing.
-- Aaron