I agree with gebi that using in-tree .hgtags file for tags which are (and must be) non-versioned, and doing the whole dance with taking most recent and not from manifest version etc. are just an error in design.

BTW. I disagree that Bazaar is not good for multiple branch workflow: you can clone branch (repository) and have it share repository data with parent, which is something in between multi-branch Git repository and Git alternates for repsitory object database.

From my understanding of GIT, its branches are simply tags that point to a head of the history DAG and are automatically updated when one does a pull from the same origin.

As a mercurial repository can store an arbitrary history DAG like GIT, one could easily work with multiple branch in the same repo simply using “hg update -C -r $HEAD” to switch branch, where $REV is the revision number or hash of the other head.

If one prefer to use names instead of revnames (hashes or numbers), he can do something similar to GIT branches by simply using local tags, but he would need to manually move the tag when he pulls. Providing an extension that does this automatically would be quite trivial.

In mercurial, named branches doesn’t need to have a single head and their name is recorded in the immutable history as it is a property of each changeset that belong to them.

This capability of recording the branch name in the history is something that GIT does not have. To be honest, GIT does not have even the ability to register simple tags in the history, while mercurial has both types of tags.

In short, they have very different usecases. The GIT branches one is already doable with mercurial (just refer to the heads with their revnames and try keep in your mind where they came from), while the mercurial named branches one is not available with GIT.

BTW, your effort with EasyGIT and the one from pyrite are very very well appreciated!

Matthew Bassett: bzr shelve is very cool. Definitely a neat tool…it has some features not present in git stash (picking out pieces of the changes to stash away, instead of just doing all changes). However, that’s not really like the index or its uses at all; there’s a small use case overlap, but not all that much. (If it was the same, git stash would be mere duplication).

Govind: Looks very cool. Kinda sad though…we have some duplication now (more on that soon).

Ali: I agree that one branch per repository is easier to grasp, and I don’t mind if the UI makes that the default and encourages it, but the system had better support multiple branches per repo or I don’t want to use it (and it appears that the one branch per repository assumption goes all the way to the core in bzr; hg at least has a good start here with named branches). I agree with you that the ideas in darcs are really cool and unique…but darcs loses on the most important criteria (see http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/). And, sure, I could start hacking on a system to add more capabilities to make up the differences to git…but git already has it. Anyway, there’s lots of things to consider in the VCS world these days and there’s lots of valid rational conclusions to come to. You can decide based on easiest to extend, most widely adopted, has most active community, has feature x or y, or other reasons. You have a good grasp of the systems and I respect your opinions and conclusion, but I have come to a different one.

Much of git is designed for use by wrappers, I am currently working on a project to wrap git functionality in a friendlier way that mimics some of what hg and others do. You can find the initial announcement at http://pyrite.sophiasuchtig.com/

My goal is to hide much of the complexity of git and facilitate certain workflows.

It goes slowly but it goes. I am also planning on having a pygtk front end that can be used.

If anyone is interested in helping, I would be glad to have it.

‘bzr commit’ does actually commit all changes

‘bzr shelve’ lets you step through the changes you have and temporarily ’shelve’ them, thus removing them from the current changes awaiting commit (and also the current working copy, until you ‘unshelve’ them).

This works well for me, since I often mistakenly work on several changes at the same time, in the same branch, and then at commit time realise I need to split these changes out into different commits.

I also am liking the merge and history functions of bzr, but bear in mind I only have svn and rcs (!!!) experience to compare to…

[2] I personally used to like this feature while using Monotone (long before git existed) but now I tend to think that from a user friendliness point of view having 1 folder == 1 branch is far easier for the user to grasp imho.

[3] I personally think that hg, git and bzr all of them got it wrong, and I tend to prefer darcs UI for this, darcs is known for its interactive ui, which in my opinion is just the best for handling the Limbo files.

[4] I agree that rewriting the history can be useful, and I don’t see what would stop you from doing this using either bzr of hg, both of them support plugins and extensions, so just go ahead and hack one(there is already bzr-rebase among others), and there is also the uncommit command.

I would like to add just one last point, basically to me Git is just a mixture of C, perl, shell … code building on top of each other to add functionalities (I am talking about the full git including its porcelain, not just the core) this makes it currently not really extensible (could you extend the existing commit for example ?). This is not the case with bzr and hg, where you have true extension mechanism, for example it would be perfectly feasible to add an plugin to bzr that would allow the –interactive option to the existing commit command, and display a text ui asking about which hunks are to be committed (in a similar fashion to darcs), or a plugin that adds a transport, or a repository format (bzr-svn adds the supports for the svn repo to bzr, unlike git-svn, this allows all the bzr commands either provided by the core or by an extension to be directly usable on an svn repository…).

Imho, since there is no real winner in this comparison, the one to be chosen ought to be the one that is the easiest to extend and improve, and not the fastest one, or the one with the most feature, or ….