Git Gui Like Bzr Explorer But for Git

A pretty and feature rich Git GUI for Linux

I find myself using mainly gitg in combination with the command line for more complicated tasks.

Source repository: http://git.gnome.org/browse/gitg.

Recently, a new version 0.3.2 has been released, which is a rewrite using Vala. It's not yet feature-complete compared to the old 0.2 series, but the refactor is expected to speed up future development.

Also, there are normally PPAS on Launchpad which contain a more up-to-date version than the standard repository.

Sample Image

Is there a way to view complete git diff using a GUI tool?

With svn I use KDE "kompare" program to view all files at ones.

Like here:

svn diff > output
kompare output

or directly:

svn diff | kompare

also there are Gnom "meld", which supposed to do the same thing (but I didn't tried it yet).

The same should be applicable for git.

Bzr gui commit tool - is one there?

QBzr/Bazaar Explorer should be part of the downloadable binaries (or can be installed as plugins, though that may require installing Qt and PyQt first).

The commands you're looking for are qcommit, qshelve, and qunshelve. The qcommit command allows you to select which files to commit, but like commit does not allow you to selectively commit only individual hunks within a file. Conversely, qshelve, like shelve, allows you to shelve changes at a finer granularity (i.e., individual hunks). Shelving can be reverted with qunshelve or unshelve commands.

Is there a Bazaar equivalent to `git commit --amend`?

bzr uncommit + bzr commit but it does not populate your editor with old commit message. If you can use bzr-gtk or QBzr then use bzr uncommit + bzr gcommit (or bzr qcommit). The GUI commit dialogs are able to populate commit editor with old commit message.

What problems can be expected with Bazaar 2.x VCS?

It depends what you're understanding by "problem". Some people are working with bzr in day-to-day basis and never encountered any problem that make their work impossible or very hard. That does not mean there is no strange features or quirks in bzr. It does mean that you can comfortable work with bzr if you understand what are you doing.

In general bzr is very pleasant to work kind of VCS, but to use it effectively you'd better know your restrictions.

If you will start working with bzr you should understand what is difference between branch, repository, shared repository and working tree. How shared repository helps you in your work and how to keep branches inside it. You should understand the differences between plain branch and checkout/lightweight checkout. If you want to continue working in CVS style you might want to use lightweight checkouts -- that's direct analog of CVS checkout and local working space on your computer.

With bzr you may find it a bit unclear how to set-up central server and set a proper access rights for all members of your team. Of course that's doable and official documentation has some examples. But proper ACL will require big help from *-nix ssh tools.

You should understand that with bzr the simplest way to refer to some revision is using its revision number. But you should know that this number is specific to specific branch, and different branches may have the same number N referring to the different revisions. So sometimes you will neeed to use unique revision identifier which is present in bzr, but that revision id is not default way to communicate with bzr because it's long and cannot be easily shortened to 8 or so characters like in git/hg. That revision numbers are determined by mainline concept, see below.

As of January 2012 you may observe the following restrictions.

With bzr you'll be forced to use mainline concept of the history. I.e. the left-hand parent of the revision is special and forms mainline of your history, while your merged revisions make merged history. Console bzr log by default shows you the mainline history, because showing the full history with merged revisions could be a bit slower for a really big history.

With bzr you won't have support for file copies, i.e. new file that continues the history of existing file.

With bzr you won't have support for CVS "modules" as the core feature. But it could be emulated by using special plugins (see bzr-externals or scmproj) to do that big project configuration work for you.

The list is not full, but that is what from time to time affects me personaly as long-time bzr user.

And the final one note. The main problem with bzr you will have is: almost everybody who uses git or hg will ask you every time: "Why did you choose Bazaar, when all guys in their company use git (or hg)".

The truth is that git is clearly winner as of January 2012 among other DVCS (git, hg, bzr, etc.) if you will count how many projects hosted on GitHub. And not only because git is superior, but because GitHub is so nice as well.

(Note for git users: I respect git, but use bzr as my own choice. Don't explain me why you think git is good, please).

how to merge changes with Bazaar explorer

Even if you can't get the e-mail work flow going, I don't think you need a VPN. It sounds like you can set up an SFTP server, give each user write access to their own repository, and give them read access to everybody else's repositories. Then you can push or commit to your own branches and pull, update, or merge from everyone else's branches.

If it's not obvious how to set that up, I'd recommend you set up an account on Launchpad to play around with branches and merging. It will probably be easier to set up your own server after you and some of your team mates have gotten a little demo project working on Launchpad.

In case it's helpful, here's a summary of my Bazaar workflow on an open-source project. It covers setting up branches, merging changes, and creating merge proposals.