GIT Basic commands

git status

git add codepool/errors/local.xml codepool/errors/local.xml.sample


git commit -m "GS-2264 removed unwanted files"


git push origin feature-GS-2337

Configure Postfix to Use Gmail SMTP on Ubuntu

If you want to use a Gmail account as a free SMTP server on your Ubuntu-Linux server, you will find this article useful. This guide is tested with Ubuntu 12.04. If you face any issue, feel free to use comments-section below.

Relaying Postfix mails via smtp.gmail.com:

First, install all necessary packages:

sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

If you do not have postfix installed before, postfix configuration wizard will ask you some questions. Just select your server as Internet Site and for FQDN use something like mail.example.com

Then open your postfix config file:

vim /etc/postfix/main.cf

and following lines to it:

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes

You might have noticed that we haven’t specified our Gmail username and password in above lines. They will go into a different file. Open/Create

vim /etc/postfix/sasl_passwd

And add following line:

[smtp.gmail.com]:587    USERNAME@gmail.com:PASSWORD

If you want to use your Google App’s domain, please replace @gmail.com with your @domain.com

Fix permission and update postfix config to use sasl_passwd file:

sudo chmod 400 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

Next, validate certificates to avoid running into error. Just run following command:

cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem | sudo tee -a /etc/postfix/cacert.pem

Finally, reload postfix config for changes to take effect:

sudo /etc/init.d/postfix reload

Testing

Check if mails are sent via Gmail SMTP server

If you have configured everything correctly, following command should generate a test mail from your server to your mailbox.

echo "Test mail from postfix" | mail -s "Test Postfix" you@example.com

To further verify, if mail sent from above command is actually sent via Gmail’s SMTP server, you can log into Gmail account USERNAME@gmail.com with PASSWORD and check “Sent Mail” folder in that Gmail account. By default, Gmail always keeps a copy of mail being sent through its web-interface as well as SMTP server. This logging is one strong reason that we often use Gmail when mail delivery is critical.

Once configured, all emails from your server will be sent via Gmail. This method will be useful if you have many sites on your server and want them all to send emails via Gmail’s SMTP server.

Alternatively, you can use a plugin like WP Mail SMTP so that mails from your particular WordPress site will be sent using Gmail’s SMTP server.

Please note that Gmail’s SMTP server has a limit of 500 emails per day. So use wisely! 

Troubleshooting

Error: “SASL authentication failed; server smtp.gmail.com”

You need to unlock the captcha by visiting this pagehttps://www.google.com/accounts/DisplayUnlockCaptcha

You can run test again after unlocking captcha.

GIT Commit-level Operation

The parameters that you pass to git reset and git checkoutdetermine their scope. When you don’t include a file path as a parameter, they operate on whole commits. That’s what we’ll be exploring in this section. Note that git revert has no file-level counterpart.

Reset

On the commit-level, resetting is a way to move the tip of a branch to a different commit. This can be used to remove commits from the current branch. For example, the following command moves the hotfix branch backwards by two commits.

git checkout hotfix
git reset HEAD~2

The two commits that were on the end of hotfix are now dangling commits, which means they will be deleted the next time Git performs a garbage collection. In other words, you’re saying that you want to throw away these commits. This can be visualized as the following:

This usage of git reset is a simple way to undo changes that haven’t been shared with anyone else. It’s your go-to command when you’ve started working on a feature and find yourself thinking, “Oh crap, what am I doing? I should just start over.”

In addition to moving the current branch, you can also get git resetto alter the staged snapshot and/or the working directory by passing it one of the following flags:

• --soft – The staged snapshot and working directory are not altered in any way.
• --mixed – The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option.
• --hard – The staged snapshot and the working directory are both updated to match the specified commit.

It’s easier to think of these modes as defining the scope of a git reset operation:

These flags are often used with HEAD as the parameter. For instance,git reset --mixed HEAD has the affect of unstaging all changes, but leaves them in the working directory. On the other hand, if you want to completely throw away all your uncommitted changes, you would use git reset --hard HEAD. These are two of the most common uses of git reset.

Be careful when passing a commit other than HEAD to git reset, since this re-writes the current branch’s history. As discussed in The Golden Rule of Rebasing, this a big problem when working on a public branch.

Checkout

By now, you should be very familiar with the commit-level version of git checkout. When passed a branch name, it lets you switch between branches.

git checkout hotfix

Internally, all the above command does is move HEAD to a different branch and update the working directory to match. Since this has the potential to overwrite local changes, Git forces you to commit or stash any changes in the working directory that will be lost during the checkout operation. Unlike git reset, git checkout doesn’t move any branches around.

You can also check out arbitrary commits by passing in the commit reference instead of a branch. This does the exact same thing as checking out a branch: it moves the HEAD reference to the specified commit. For example, the following command will check out out the grandparent of the current commit:

git checkout HEAD~2

This is useful for quickly inspecting an old version of your project. However, since there is no branch reference to the current HEAD, this puts you in a detached HEAD state. This can be dangerous if you start adding new commits because there will be no way to get back to them after you switch to another branch. For this reason, you should always create a new branch before adding commits to a detached HEAD.

Revert

Reverting undoes a commit by creating a new commit. This is a safe way to undo changes, as it has no chance of re-writing the commit history. For example, the following command will figure out the changes contained in the 2nd to last commit, create a new commit undoing those changes, and tack the new commit onto the existing project.

git checkout hotfix
git revert HEAD~2

This can be visualized as the following:

Contrast this with git reset, which does alter the existing commit history. For this reason, git revert should be used to undo changes on a public branch, The parameters that you pass to git reset and git checkout determine their scope. When you don’t include a file path as a parameter, they operate on whole commits. That’s what we’ll be exploring in this section. Note that git revert has no file-level counterpart.

Reset

On the commit-level, resetting is a way to move the tip of a branch to a different commit. This can be used to remove commits from the current branch. For example, the following command moves the hotfix branch backwards by two commits.

git checkout hotfix

git reset HEAD~2

The two commits that were on the end of hotfix are now dangling commits, which means they will be deleted the next time Git performs a garbage collection. In other words, you’re saying that you want to throw away these commits. This can be visualized as the following:

This usage of git reset is a simple way to undo changes that haven’t been shared with anyone else. It’s your go-to command when you’ve started working on a feature and find yourself thinking, “Oh crap, what am I doing? I should just start over.”

In addition to moving the current branch, you can also get git reset to alter the staged snapshot and/or the working directory by passing it one of the following flags:

--soft – The staged snapshot and working directory are not altered in any way.

--mixed – The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option.

--hard – The staged snapshot and the working directory are both updated to match the specified commit.

It’s easier to think of these modes as defining the scope of a git reset operation:

These flags are often used with HEAD as the parameter. For instance, git reset --mixed HEAD has the affect of unstaging all changes, but leaves them in the working directory. On the other hand, if you want to completely throw away all your uncommitted changes, you would use git reset --hard HEAD. These are two of the most common uses of git reset.

Be careful when passing a commit other than HEAD to git reset, since this re-writes the current branch’s history. As discussed in The Golden Rule of Rebasing, this a big problem when working on a public branch.

Checkout

By now, you should be very familiar with the commit-level version of git checkout. When passed a branch name, it lets you switch between branches.

git checkout hotfix

Internally, all the above command does is move HEAD to a different branch and update the working directory to match. Since this has the potential to overwrite local changes, Git forces you to commit or stash any changes in the working directory that will be lost during the checkout operation. Unlike git reset, git checkout doesn’t move any branches around.

You can also check out arbitrary commits by passing in the commit reference instead of a branch. This does the exact same thing as checking out a branch: it moves the HEAD reference to the specified commit. For example, the following command will check out out the grandparent of the current commit:

git checkout HEAD~2

This is useful for quickly inspecting an old version of your project. However, since there is no branch reference to the current HEAD, this puts you in a detached HEAD state. This can be dangerous if you start adding new commits because there will be no way to get back to them after you switch to another branch. For this reason, you should always create a new branch before adding commits to a detached HEAD.

Revert

Reverting undoes a commit by creating a new commit. This is a safe way to undo changes, as it has no chance of re-writing the commit history. For example, the following command will figure out the changes contained in the 2nd to last commit, create a new commit undoing those changes, and tack the new commit onto the existing project.

git checkout hotfix

git revert HEAD~2

This can be visualized as the following:

Contrast this with git reset, which does alter the existing commit history. For this reason, git revert should be used to undo changes on a public branch, and git reset should be reserved for undoing changes on a private branch.

You can also think of git revert as a tool for undoing committed changes, while git reset HEAD is for undoing uncommitted changes.

Like git checkout, git revert has the potential to overwrite files in the working directory, so it will ask you to commit or stash changes that would be lost during the revert operation.and git reset should be reserved for undoing changes on a private branch.

You can also think of git revert as a tool for undoing committedchanges, while git reset HEAD is for undoing uncommitted changes.

Like git checkout, git revert has the potential to overwrite files in the working directory, so it will ask you to commit or stash changes that would be lost during the revert operation.

How can I use grep to find a word inside a folder?

grep -nr yourString* .

The dot at the end searches the current directory, and -r searches sub-directories.

grep -nr MobileAppSer* . (Will search for MobileAppServlet.java or .class or .txt; MobileAppASer*.* is another way to do the same thing.)

How To Install the Firefox Developer Edition in Linux Ubuntu 14.10, Ubuntu 14.04 & Others

Method 1

• Install Firefox Developer Edition, formerly know as Aurora by running the following commands:
  
sudo add-apt-repository ppa:ubuntu-mozilla-daily/firefox-aurora
sudo apt-get update
sudo apt-get install firefox

  Ubuntu versions supported: Utopic (14.10), Trusty (14.04), Precise (12.04).

Note that this method will replace your current Firefox installation.

Method 2

• Download the firefox developer edition here:
  https://www.mozilla.org/en-US/firefox/developer/
• Extract the file manually to /opt/firefox/
• Open Nautilus: Go to Edit->Preferences-> Behavior-> click on “Run executable text files when they are opened”
• Go to the file ‘firefox’ in /opt/firefox/
• Right click and select Properties–> Permissions–> Execute: Allow executing file as a program.
• Open terminal and type:
• 'gnome-desktop-item-edit' not installed in your computer then you want to run following command
  

sudo apt-get install gnome-panel

then run following command

gnome-desktop-item-edit ~/.local/share/applications --create-newCreate a shortcut and it’s done.