Posts Tagged ‘mercurial’

Painless git diff

February 2, 2013

I’ve been using Node.js quite a bit lately and decided it was time to start using Git for my projects.

I’m used to using Mercurial (Hg) for DVCS, but have only used it on Windows and a little on Linux via command line.

I was looking for a similar experience that Windows gave me for Hg (file explorer integration with tortoisehg), but for Linux. I had created a repository using tortoisehg. When I attempted to add files to the repository using tortoisehg or straight from the command line, I was getting a few errors. tortoisehg, nautilus integration is broken on my distro at the time of writing this too. So this encouraged me to invest a little more time in Git. I had done a bit of reading and listened to a few good podcasts on Git, so I felt it was a good time.
think like a git is also good for a read.

As I was creating repositories, dealing with remote repositories, cloning, setting up all the config files, adding, committing, pulling, pushing, viewing status and diffing. What I quickly came to realise, was that the Git commands were very extensive, made more sense to me than Hg, and there is a lot of good documentation around. In saying that, it’s been a while since I used hg from the command line and most of my work has been through the GUI tools.

One area I was struggling with was the diffing of files and directories on the command line. There are a couple of good ways to make this experience a lot more pleasurable.
I like using meld on Linux for my file and directory comparisons, so already had that installed.

git diff

Create a bash file in the /bin directory.
I called it git-meld, and it looks like the following:

meld $2 $5

Turn the executable bit on, so it can be executed.

chmod git-meld +x

Now modify your ~/.gitconfig file

git config --global diff.external git-meld

To make sure your’ve added git-meld as the script that’ll run meld with the correct parameters:

cat .gitconfig

and you should see at least the following:

external = git-meld

Now that should be all you need to get git to pop meld on diff.

git diff [options] <commit> <commit> [<path_to_file_to_compare>]

If you have a stack of files (rather than just one, as shown in my above example) that were changed between these commits, diff will pop each file open in meld. One at a time until you’ve finished with each one


git difftool

git also comes with difftool. I found this really nice to use. There is no setting up for it. All you do is replace the diff command with difftool. Optionally you can specify the GUI diff tool you want to use, simply by appending -t [your_GUI_diff_tool] like this if you like using meld.

git difftool -t meld <commit> <commit> [<path_to_file_to_compare>]

If you do this without specifying the file you want to compare, you are prompted if you want to view each file, rather than how diff works by just opening every one.


If you choose to leave the -t option out, difftool will give you the option of all the possible tools able to perform the diff (some of which may need installation).

multiple diff tools

So using difftool is a better diff IMHO. This is how git difftool behaves whether or not you set up ~/.gitconfig file with your prefered diff tool.



December 3, 2011

Some differences between Distributed Version Control Systems (DVCS) and Centralised Version Control Systems (CVCS)

The central server dilemma

I hear a number of people being fearful about what they hear about DVCS not having a central repository.
In most cases this is not entirely true.
There are a number of DVCS models that work very well utilising one or more central servers.
In fact all the DVCS I’ve worked with or set-up have used one or more central repositories.

One of the key differences between Distributed and Centralised.
Is with distributed, the authoritative or central source is the source you want it to be, rather than being constrained by the system into having to have your source in one place.
There has been occasions where we have had to use one of the developers local repositories when the central server has been down.
This is simply making a decision that the entire team is aware of, that you are going to push / pull to / from an alternative repository.
Hg has it’s own inbuilt web server, so this is very easy to do.

One of the big advantages with a DVCS is the flexibility.
With increased flexibility and power, comes the increased likelihood of someone screwing something up.
Personally I’d much rather have the extra flexibility.

Branching Merging

Is easy and encouraged in DVCS.
DVCS are designed with branching and merging to be a common task.
Therefore they do it well, and some of the paranoia around this concept is no longer justified when you go distributed.

Mercurial (Hg) vs Git commits

Both Hg and Git are distributed.
Git has this extra step between your working directory and your repository called the Index (strangely enough)
All changes in git go into a staging area, then into your repository.
The index is used to combine a set of changes that you want to commit as one operation.
When you commit, what is committed is the contents of your index rather than your working directory.

The idea of the index, is that some of the history is erased once a commit is made, as multiple changes and their details are wrapped into a single commit.
There is a philosophical debate as to which way is better.
Is it better to have every change recorded, or is it better to have a bunch of changes wrapped into an atomic change, so that some detail is negated.
I’m kind of on the fence about this one, as I think there are pros and cons for both arguments.

Interfacing with Hg and Git for Windows users

There are currently several options here.

command line

file explorer

  1. TortoiseHg
  2. TortoiseGit
  3. GitExtensions for Explorer and Visual Studio integration

For Visual Studio users

  1. Git Source Control Provider also
  2. VisualHg