Ubuntu: how to add “Open in Terminal” to the Nautilus context menu
This one is easy:
- Install nautilus-open-terminal package.
- Restart Nautilus.
This one is easy:
This is a step-by-step guide on installing Mercurial and TortoiseHg on Ubuntu, and setting up a BitBucket account. This was tested on Ubuntu 12.04 LTS and Ubuntu 12.10.
Add TortoiseHg PPA (https://launchpad.net/~tortoisehg-ppa/+archive/releases
)
sudo add-apt-repository ppa:tortoisehg-ppa/releases
sudo apt-get update
sudo apt-get install tortoisehg tortoisehg-nautilus
That installs Mercurial 2.5.1 and TortoiseHg 2.7.
TorstoiseHg Workbench should open.
Then select File | Settings from the top menu.
In the Commit section enter the username that will be used with commits.
The common format is: Full Name (e.g. Valentin Kantchev )
sudo apt-get install python-setuptools
sudo easy_install keyring
sudo easy_install mercurial_keyring
Add these lines to the .hgrc (in your home directory):
That allows Mercurial to store and use user credentials in the Ubuntu keychain.
Add these lines to your global .hgrc (i.e. /home/valentin/.hgrc), change the username to your own:
My final .hgrc
looks like this:
# Generated by TortoiseHg settings dialog
[ui]
username = Valentin Kantchev
[auth]
bitbucket.org.prefix = bitbucket.org/<myteamname>
bitbucket.org.username = <mybitbucketuser>
[extensions]
mercurial_keyring =
This post describes setting up Git on Windows and using a private remote Git repository hosted on BitBucket.org. Here it goes:
1) Start by downloading Git fromthe msysgit site. At the time of writing the latest installer was Git-1.8.1.2-preview20130201.exe. For some unknown reason the installers are labeled “preview” which normally suggests unfinished product, but the versions are actually fully functional.
After downloading, run the installer and follow the steps. You may use the default options on each screen, but since we are going to try TortoiseGit later, on the first screen select “Simple context menu (Registry based)” and check only “Git Bash Here”. That will keep to your Windows Explorer context menu less cluttered.
2) Install TortoiseGit. At the time of this writing the latest version was 1.8.1. There is nothing special about installing TortoiseGit.
To verify the TortoiseGit installer integrated with your msysgit installation: right click anywhere in Windows Explorer and select TorstoiseGit > Settings from the context menu, then make sure you have the correct paths for Git.exe under the General section and the ssh client under the Network section.
3) Install the Credential Caching Git extension. We will be using Git via https://
instead of ssh
and that extension caches the username and password, so we do not have to type them all the time. Download git-credential-winstore and GitPad for Windows 8 (.NET 4.0 required), unzip,copy git-credential-winstore.exe to the Git bin directory and run it. By default Git is installed in C:\Program Files (x86)\Git\bin
on 64 Bit systems. Open your global .gitconfig file. The global .gitconfig file is in your home directory which on Windows Vista and above should be under C:\Users\<yourname>
. Verify the you have this line in .gitconfig*:
4) Optionally you may want to change the default text editor that Git uses, e.g. you might need that for commit messages. The default editor in msysgit is Unix VIM. You can change that to Notepad with GitPad – a small utility found in the credential caching extension zip. Simply copy GitPad.exe inC:\Program Files (x86)\Git\bin and run it.
5) Create an empty Git repository onBitbucket.org – that will be your shared repository. If you are new to BitBucket you can check this shorttutorialon how to create a BitBucket account and a Git repo- the process is rather straightforward. For this demo create a repo and name it SandboxGit. Please note that BitBucket will create a bare repository. A bare repository is one without branches.
6) We are now ready to start playing with the SandboxGit repo. If you are new to Git, it is better to start in Git Bash at the beginning just to get a feeling of Git. Knowing Git command line will help you understand what TortoiseGit or any other GUI tool does later, because in almost all cases, all the GUI tools generate and execute Git commands for you.
In Windows Explorer, go to a place where you want to put your working directory, right click and selectGit Bash Herefrom the menu.
In Git Bash prompt enter:
After the changes, C:\Users\<yourname>\.gitconfig
should have the user configuration in it:
[credential]
helper = !~/AppData/Roaming/GitCredStore/git-credential-winstore
[user]
name = user
email = user@domain.com
Also we can get the same result with the git config
command:
git config --global -l \
credential.helper=!~/AppData/Roaming/GitCredStore/git-credential-winstore \
user.name=user \
user.email=user@domain.com
Without that we will get CR/LF conversion warning on each commit, e.g. something like this will be shown for each new line in your source:
warning: LF will be replaced by CRLF in HelloWorld.cpp.
The file will have its original line endings in your working directory.
Modern development tools support both CR/LF and LF line endings, so we do not need Git to do line ending conversion.
git clone https://user@bitbucket.org/primosoftware/sandboxgit.git ./SandboxGit
Cloning into './SandboxGit'...
warning: You appear to have cloned an empty repository.
The first time you do this Git will ask for a BitBucket.org password. After that it will remember the password, because of the credentials caching extension thatwe installed in step 3.
``` bash cd ./SandboxGit git remote show origin
``` bash
git remote show origin
* remote origin
Fetch URL: https://user@bitbucket.org/primosoftware/sandboxgit.git
Push URL: https://user@bitbucket.org/primosoftware/sandboxgit.git
HEAD branch: (unknown)
Local branch configured for 'git pull':
master merges with remote master
Basically we have:
origin
alias that points to a remote repo at https://user@nullbitbucket.org/primosoftware/sandboxgit.gitmaster
that will merge with the remote branch master
. However, the remote master
branch does not exist yet. It will be created when we do our first commit and push.Think of HEAD as a symlink/shortcut to a branch. The HEADis unknown because there are no branches in the remote repository yet. Normally HEAD points to themasterbranch.
In the SandboxGit folder create a fileHelloWorld.cppwith some code in it. For example:
#include <iostream>
using namespace std;
void main()
{
cout << "Hello World!" << endl;
cout << "Welcome to Git" << endl;
}
In Git Bash do git add HelloWorld.cpp
:
git commit
– enter “Initial commit.” when Git asks for a commit message.
git commit .
[master (root-commit) 8ed71ed] Initial commit.
1 file changed, 7 insertions(+)
create mode 100644 HelloWorld.cpp
The commit is local. Up to this point we have done local changes only. The remote repository on BitBucket.org is still untouched.
In order for others to see the changes we have to push the changes to the remote location. That is done with thegit push command.
Git pushcan work in one of two ways:
We will use the simple push:
git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 322 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: bb/acl: user is allowed. accepted payload.
To https://user@bitbucket.org/primosoftware/sandboxgit.git
* [new branch] master -> master
Verify that now we have a remote branch called master:
``` bash git remote show origin * remote origin Fetch URL: https://user@bitbucket.org/primosoftware/sandboxgit.git Push URL: https://user@bitbucket.org/primosoftware/sandboxgit.git HEAD branch: master Remote branch: master tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)
We are done.
#### Configure default name and email for commits
Right click anywhere in Windows Explorer and select **TorstoiseGit > Settings** from the context menu, then enter your name and email on under the **Git** section.
![tortoisegit-git-settings-config-name-email](../assets/images/getting-started-with-git-and-bitbucket-on-windows/tortoisegit-git-settings-config-name-email.png)
Click *Edit global .gitconfig*. Verify that the *.gitconfig* file now contains the user configuration:
``` ini
[credential]
helper = !~/AppData/Roaming/GitCredStore/git-credential-winstore
[user]
name = user
email = user@domain.com
Again in the TorstoiseGit > Settings > Git section, in the "Auto CrLf convert" group, uncheck the AutoCrlf box.
Without that we will get CR/LF conversion warning on each commit, e.g. something like this will be shown for each new line in your source code:
warning: LF will be replaced by CRLF in HelloWorld.cpp.
The file will have its original line endings in your working directory.
Modern development tools support both CR/LF and LF line endings, so we do not need Git to do line ending conversion.
In Windows Explorer, go to a place where you want to put your working directory, right click and select Git Clone from the menu.
Right click on the SandboxGit
folder in Windows Explorer and select TorstoiseGit > Settings from the context menu, then go to the Git > Remote section. Verify the remote url to which the origin alias points.
In the SandboxGit folder create a fileHelloWorld.cppwith some code in it. For example:
#include <iostream>
using namespace std;
void main()
{
cout << "Hello World!" << endl;
cout << "Welcome to Git" << endl;
}
Right click on the HelloWorld.cpp
file and select TortoiseGit > Add. Check the HelloWorld.cpp
file and click OK.
Right click on the HelloWorld.cpp
file again and select Git Commit -> Master. Enter “Initial commit.” for a message. Check the HelloWorld.cpp
file and click OK.
The commit is local. Up to this point we have done local changes only. The remote repository on BitBucket.org is still untouched.
Right click on theSandboxGitfolder in Windows Explorer and select TorstoiseGit > Push from the context menu. Click OK.
We are done.
This post summarizes the Mercurial subrepository vs the Subversion externals experience. This is the third and last post of a multi-part article about Mercurial subrepositories. Please make sure you read Part 1 and Part 2 before reading this post.
In a few words, Mercurial subrepositories are very similar to Subversion “svn:externals” and can be used pretty much the same way. However, there are some differences in the workflow, because of the distributed nature of Mercurial. Here are the main differences from Subversion:
On good thing about the pull+update workflow is that, it guards against accidentally losing local changes and allows you to do code merges at your convenience.You can also revert an update and continue in your local copy when an update breaks a lot of code and requires hard manual merge labor. You can update your working copy again later, when you are ready for the code merge.
This is the second post of a multi-part article about Mercurial subrepositories. Please make sure you read Part 1 before reading this post.
In Part 1 of this series we created a Mercurial container SandboxRootHgrepository and Mercurial repositories for the main project -SandboxHg,and its two depencies – SandboxDep1Hg andSandboxDep2Hg. Then we added the main project and dependency projects as subrepositories to SandboxRootHg.
In this post we will go through a Change / Push and Pull / Update cycle for the subrepositories. If you followed the steps in Part 1 you will end up with a SandboxRootHgstructure similar to the one shown on this screenshot:
Notice the .hgsubstate file. Mercurial added this file to track the subrepository revisions. We will get back to examine this file when we make changes to the projects and we synchronize those changes with the remote shared repository.
To simulate a two machine setup I simply cloned the SandboxRootHgshared remote repository to two separate folders named Work and Home respectively. After that I created two groups in TortoiseHg Workbench registry and rearranged the groups and the repositories to reflect my new directory structure. Here is another screenshot:
We are now ready do do some testing.
Go to the Home folder and add a new file TestFile-1.txt to the SandboxRootHg/SandboxHg folder, right click on the new file and select TortoiseHg/Add Files from the menu, then do Hg Commit. So far the changes have been committed to your local repository clone. You still have to Push the changes to remote shared repository. You can do that in the Synchronize view ofthe TortoiseHg Workbench.
Now go to the Work folder,right click onthe SandboxRootHg folder and select Hg Workbench from the menu. Switch to Synchronize view and pull the changes from the remote repository. Hmm.. Nothing came in the Work/SandboxRootHg/SandboxHg folder. We should have received a change set with the TestFile-1.txt. What happened? We added TestFile-1.txt in Home/SandboxRootHg/SandboxHg, committed and pushed the change to the remote server. However we forgot to commit and push the change in the container repository: Home/SandboxRootHg. Right click on Home/SandboxRootHg and select Hg Commit from the menu.
If you open the .hgsubstate file under the Home/SandboxRootHg folder you will see that after the commit the Mercurial updated the revision id of the SandBoxHg project. The .hgsubstate contents changed from this:
0000000000000000000000000000000000000000 SandboxDep1Hg
0000000000000000000000000000000000000000 SandboxDep2Hg
0000000000000000000000000000000000000000 SandboxHg
to this:
0000000000000000000000000000000000000000 SandboxDep1Hg
0000000000000000000000000000000000000000 SandboxDep2Hg
4090583f58e67f599b5141ed2551be3eb4fe5c8c SandboxHg
Now all we have to do is Push the Home/SandboxRootHg changes to the remote shared repository.
Go again to the Work folder,right click on SandboxRootHg and select Hg Workbench from the menu. Switch to the Synchronize view and pull the changes from the remote repository. This is how my Hg Workbench looks like after the update:
Notice on the screenshot above that our working copy still does not have the latest code in it. TortoiseHg makes alerts us by displaying the “Not a head revision!” message in red. One of the differences between Mercurial and Subversion is that in Mercurial you have a two-step code update. Basically the Hg/Pull command only downloads the latest change sets from a remote shared repository. After you pull the changes you still have to apply them by issuing an Hg/Update command.
Go to the Work folder, right click on the SandboxRootHg folder, and select TortoiseHg > Update from the menu. This updates our working copy with the changes we downloaded when did Hg/Pull.
If you check the Work/SandboxRootHg/SandboxHg folder you will see that the TestFile-1.txt file is now there as it should be.
Continue to Hg subrepositories: a how-to guide for the “svn:externals” junkie (Part 3)