One question : You'll still be able to commit code from the private to the public repo even if you squashed the changesets/history in the public one ??? I most probably don't understand properly as I'm not sure how that would work.

Well, I'm still not 100% on how it works under the hood, but the idea is that after "going public", you don't touch the old private repo, you keep doing all new development in the public one, and the private is kept just for the history - but is able to show entire history.

In any case, I've edited Mercurial's ini file to add the "collapse" extension and it seems to load properly. Haven't properly tested it yet. Collapsing changesets is probably not too dangerous when working alone, but I don't know about team work. Potential for disaster.

As long as you don't collapse changesets that have already been pushed, you should be fine - so do all your crazy-small local commits, collapse changesets to your liking, then push remotely and you should be fine

@f0dder : Thanks for the explanations.
@Everyone here : I read a lot and have been playing with Git and Mercurial quite a bit in the last 2 days.


A- Intro

It looks formal, but it's not. (I don't have enough time to "formalize" as much as I'd like to...)
It's only... There's a lot of info that I'd like to share. I'll split it in a few parts and today I'll talk about less technical aspects.

Wow... amazing how much false or half true infos on Git and Mercurial you’ll find out there! Even Google’s analysis, while still very good, seems a bit inaccurate. "They" favoured Mercurial over Git, but without even detailing some of their biggest differences -- e.g. : the important repercussions Git's index has on the way some features are implemented... but more about that later. Basically, a lot of the articles are just repetitions of what has been said on various blogs all over the Web, without even trying to do a bit of research. Fortunately there are also excellent books and resources out there (like the official manuals…).

So, what about Git? I must say I’m thoroughly impressed. The question remains though : should I use Git or Mercurial ? Which one is better for my needs? Still hard to say.


B- Experiments

I've tried all kinds of things, with both Mercurial and Git. Like merging branches and collapsing changesets and other stuff (git rebase -i HEAD~n , hg collapse –r  n:m … The hg collapse is actually a bit slicker, I find, than the rebase interactive, etc. ) with some success. I can see that one or the other will work well, providing I'm not blindingly committing and editing stuff. Who would do that anyway.

However, while they are certainly quite similar, they of course have some pretty interesting differences. And those differences make them both attractive in their own way.


a. The general Feel... going from Git to Hg, and Hg to Git

Switching between Mercurial and git, some commands can become confusing : Mercurials Pull and Fetch do exactly the reverse of Git's Pull and Fetch ! Careful there...  

The Mercurial document about Mercurial/Git's differences is usually accurate (of course, it doesn't talk about a few things... like files renaming, intelligent "blame"… but more about that later) but it can be misleading as some features aren’t implemented exactly in the same way and just don’t have the same options.

Some programmers — like Steve Losh - stress how each system feel very different to use (and how that's very important...) :

Each git command is like a Swiss Army knife. For example, git checkout can switch the working directory to a new branch, update file contents to that of a previous revision, and even create a new branch. It’s an efficient way to work once you learn all the arguments and how they interact with each other.

Mercurial is like a well-equipped kitchen — it has a lot of tools that each do one simple, well-defined thing, and do it well. To switch the working directory you use hg update. To update file contents to what they were at a previous revision you use hg revert. To create a new branch you use hg branch. This means there are more commands to learn, but each command is much simpler and more specific to a single conceptual task.

I think I generally agree (of course, as you probably guessed, Mr Losh prefers Mercurial... well… at the time he wrote the article). Generally speaking, and there's nothing new there : “Git is considered to have a steeper learning curve than Mercurial due to a number of factors. Git has more commands and options, the volume of which can be intimidating to new users”, as Mr Google puts it.


b. Performance ?

On the performance side, both are fast.

Relatively speaking though, Git is certainly not always fast. In fact, in 2009, it lost a few benchmark “battles” (note that it could different today — numbers change all the time as the software evolve) :

1 As a benchmark, Git and Mercurial repositories were seeded with approximately 1500 files totaling 35 M of data. The servers were running in Chicago and the clients in Mountain View (51 ms ping time). The operation of cloning the remote repository (similar to a initial checkout in traditional version control systems) averaged 8.1 seconds for Mercurial and 178 seconds for Git (22 times slower). A single file in the repository was then changed 50 times and the clients pulled the updates. In this case, Mercurial took 1.5 seconds and Git required 18 seconds (12 times slower). When the Git protocol was used instead of HTTP, Git's performance was similar to Mercurial (8.7 seconds for cloning, 2.8 seconds for the pull).

Even Git’s repo’s size variations can be aproblem. All and all, on Linux, Mercurial seem to produce more stable repositories size and is really speedy. Which seems to confirm Google’s conclusions. See : http://draketo.de/proj/hg-vs-git-server/test-results.html

---

Now, what about windows usage/performance per se… There are not that many recent numbers that I found. But Git made significant progresses in the last 2 years, implementing smart HTTP support (Mercurial vs Git; it’s all in the branches) to solve some of the speed problem. On the windows GUI side, it’s the same thing : a lot of different and good options for Git.


Anyway... Generally speaking, both are fast (many other benchmarks can be found to prove that) and what needs to be remembered here is that Mercurial is most probably not less efficient than Git. If anything, it’s at least probably more efficient for certain tasks.


c. GUIs...

Like I just said, there are many GUIs for Git. SmartGit, which Shades suggested earlier is really really nice. Nicer than TortoiseGit IMO, but not free if you use commercially.

TortoiseGit is also a great Gui. I actually found it as polished as TortoiseHG (used it only for 2 days so your mileage may vary). It looks slicker : the icons are nicer, the chosen fonts too, etc. (IMO) and a lot can be done directly from its interface. However, I found that the buttons/commands to show the main interface component/windows are hard to find at first. This is something that’s much clearer with TortoiseHG.

And then there are others like Git Extensions, which are very nice too, not to mention the ones which are bundled with Windows Git by default : Gitk, Git GUI.

For Mercurial, as you guessed, the best is certainly TortoiseHG. But there are lots of other options and/or IDE add-ons. See : http://mercurial.selenic.com/wiki/OtherTools

Now… whatever the Gui, you'll still have to drop to the command line once a while to access some of the "not yet GUIified" commands. Git is complex and powerful and so is Hg... especially with all the extensions.

Parenthesis : As Deozan mentioned, it’s often easier to just learn the commands and use the command line. One of the problem these GUIs have is that they aren’t always following exactly the same “command line terminology”, which can be confusing. Instead, they’ll use more high level metaphors (e.g. : “stage” instead of “git add” or simply “add” — this refers to the git’s “staging” of data in the index before committing).


OK... enough for tonight. Tomorrow, hopefully, I'll tackle Git’s Index, File rename , Code/txt move detection, Branching, and maybe Merging. And next... We'll see.  Maybe tags, revision numbers, or Expendability and collaboration tools...

Armando: nice post - DoCoCoins coming your way. More, please!

On speed: first, you have to do some manual cleanup of Git repositories every once in a while, to do garbage collection and (re)pack the repository - this helps wrt. speed and disk space consumption. This can of course be automated, but it's something you have to automate, Git doesn't do it for you.

Thanks f0dder. I appreciate.

Yes, thanks for reminding me of git gc -- I wasn't going to touch that area, but now I should. 

There are lots of posts and paragraphs in articles everywhere mentioning the need to "git gc" (with various flags...) to keep the repository in good shape. The git-gc(1) Manual Page states it pretty clearly :

"Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance."

However, there's also this part :

Some git commands may automatically run git gc; see the --auto flag below for details.

From what I've read (manual, online books), the need to repack and call git gc is much less significant with newer Git releases as many of the commands that cause the repository to grow automatically run git gc for you.

From Pro Git (one of the best reference out there):

Occasionally, Git automatically runs a command called “auto gc”. Most of the time, this command does nothing. However, if there are too many loose objects (objects not in a packfile) or too many packfiles, Git launches a full-fledged git gc command. The gc  stands for garbage collect, and the command does a number of things: it gathers up all the loose objects and places them in packfiles, it consolidates packfiles into one big packfile, and it removes objects that aren’t reachable from any commit and are a few months old.

You can run auto gc manually as follows:


$ git gc --auto


Again, this generally does nothing. You must have around 7,000 loose objects or more than 50 packfiles for Git to fire up a real gc command. You can modify these limits with the gc.auto and gc.autopacklimit config settings, respectively.

Which commands run git gc automatically ? Someone did a git grep -- --auto on stackoverflow. He writes :

builtin/merge.c:            const char *argv_gc_auto[] = { "gc", "--auto", NULL };
builtin/receive-pack.c:    "gc", "--auto", "--quiet", NULL,
git-am.sh:                  git gc --auto
git-rebase--interactive.sh: git gc --auto &&
git-svn.perl:              command_noisy('gc', '--auto');


From git grep -- --auto on git.git, those results looked interesting. The notable one is builtin/merge.c meaning that the ever so common git pull should trigger a git gc --auto.

Additionally, unless your 'non-technical' staff is doing rather 'advanced' stuff (at which point they wouldn't be 'non-technical' anymore), I don't see why they would ever need to run git gc manually instead of just letting git gc --auto handle everything.

Now, you're right. Maybe once in a while, especially for big repos and server stuff, a git gc might be a good idea. But I don't see it as anything urgent and absolutely necessary.

--

The conclusion of this very recent (2011-01-25) benchmark (link also provided in my previous post) is quite interesting :

If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go. Note that its speed drops to half the speed of Mercurial (and less for big repositories, since the time for the garbage collection rises linearly) if Git is forced to avoid frequently growing and shrinking repositories by running the garbage collection every ten commits. Also note that git gc --auto allowed the repository to grow to more than 5 times the minimum size and that garbage collection created 100% load for 3 of my 4 cores which would slow down all other processes on a server, too (otherwise gc would likely have been slower by factor 3).

If you need reliable performance and space requirements, Mercurial is the better choice, especially when called directly via its API. Also for small repositories with up to about 200 commits, it is faster than git even without garbage collection.

... 

Also, there's definitely been a lot of progress in Git over the years. Considering that more and more has been going from shell scripts -> native C code, it's probably not fair looking at a 2 years old benchmark

You're absolutely right. The tests mentioned above are the most recent I could find, but there are not many.

On Tortoise... I've been considering moving away from it. Yes, the icon overlays in explorer are kinda nice, but that's about it - I feel that a dedicated app would probably provide more efficient workflows. Also, having cache processes for t-svn, t-git, t-hg seems a bit much, and I often run into problems with those processes keeping folders locked when they shouldn't.

Dunno which app(s), though - I wasn't all impressed when I checked out SmartGit, but can't remember exactly why, guess I'll give it another chance. I think my 'meh' was partially causes by the program being implemented in Java, and (worse) not having an option to use the system JDK but installing it's own separate copy.

I find that all these GUIs have limitations. And, yes, having all these tortoise running at the same might cause some caching problem. Although I've read that they're now supposed to play well together (speaking of the icons overlay here).

I don't care about the overlay anymore as it's a bit unreliable. I mostly use the "tortoise explorer" on TortoiseHG an the "log" and "commit" windows/dialogs  in TortoiseGit. I use the command line git status or hg status to find out what's up with the changes. 

Now... SmartGit as a dedicated app definitely seems the most viable, and it's performing quite well. I haven't had any problem (yet) with it. You just need to get use to the UI a bit and you should be okay. It might be implemented in Java, but, honestly, it's not apparent and its performance is quite good.

-----

More later... But maybe tomorrow as I'm running out of time, even if the subject is highly interesting.

[Edited : formatted code a bit...]
[Edited :grrrr. Font problems..]

More on GUIs.

I could edit my previous post, but I’m sure nobody would notice.  

After spending many hours fiddling with Git and Hg, TortoiseHg, SmartGit, TortoiseGit and “Git Extensions”, etc. I came to the conclusion that Hg/git GUIs are ok but… somewhat disappointing.

- Most are percetly fine for basic operations and still very convenient, but for more complex operations (e.g. : git rebase –i HEAD~n), the command line is still better and more transparent. You’re much more sure about what’s happening, you can actually “see” it.

[- And as f0dder will later say : they feel rough around the edge (questionable interface choices and aesthetics...), not always super responsive, etc.]

ii. Git… GUIs

Now… What about these Guis…? Here are 4 very short and very imperfect reviews of what seem the most popular ones on Windows.

Don't know if it'll be useful to anybody, but here are some thoughts…

 1. Git GUI

This is what could be called the "default" Git GUI. it can be accessed through the command line : "Git gui"

It does come by default when you download Git for Windows. As far as this default is concerned, it's MUCH better than the “default” Hg one I mentioned in my last post about Hg (Mercurial) GUIs.

“Git GUI” is very “late 90s Linux like” : a bit ugly but relatively functional. It does what it does pretty well and can even easily do stuff that you can’t do as easily/intuitively (or even at all...) with other programs (e.g. : TortoiseGit). E.g. : “staging/commiting a few lines at a time instead of whole file changed/diff content, (aka hunk) — so you can split a big commit into several smaller ones (note that in real life using this feature this can be tricky as you won’t have necessarily tested these fractioned commits…).

Like TortoiseGit, Git GUI adds an explorer shell extensions to the mix (i.e. : explorer context menu items) : Git Commit, Git Branch, Git History, Git Bash, etc. Those can be pretty handy when you’re browsing your repo and don’t want to type a command just to add a few files or commit a small change.

Keyboard navigation is okay, not great. Certainly better than TortoiseHG though.

I did run into some problems (errors) when I tried to stash (not stage -- different thing) some changes — maybe was it a one time glitch?

While not beautiful, the graph logs looks nicer than TortoiseGit’s one… subjective I guess.

Overall, I kinda like the "no frills" Git GUI. "Rough around the edges" (2011 03 15 -- 10 46 : see f0dder comment, later), but simple and effective for most important Git commands.


  2. SmartGit

SmartGit, an “easy on the eyes” and comfortable to configure commercial solution, which I mentioned in an earlier post, isn’t *that* great after all.  Well… Ok it IS… pretty good. Probably the best feel overall. There’s certainly nothing equivalent for Hg and the other Git solutions don’t look as polished. It doesn't have the rough and unfinished feel to it.

In SmartGit, most Git commands are achieved quickly and intuitively. Great.

It has all of the most important commands one will need to use Git on a day to day basis. Plus it does a few more advanced things, like edit the Git index and manage sub-modules. Nice.

It does miss some other important ones though, like “blame”, “stash”, “clone –bare” (last one : surprising, to say the least… Unless I missed something ).

Keyboard usage/navigation (shortcuts, “configurability”…) is very good too. Not perfect maybe, but better than all other solutions as it’s configurable (the log view and main/review views offer a “customize” dialog through the "edit" menu, which allows the user to add/edit shortcut keys).

A few maybe insignificant other things I also like about SmartGit: 1- the nice, clean and flexible interface (did I already say it?), 2- the easy well organized and “intuitive” configuration dialog (e.g. : out the box github config — plus a few others source code hosting web solutions like Unfuddle and Codebase —, + other very intuitive Git configuration) 3- and little details like the fact that it refreshes its interface automatically when changes are made to the repos (no need to refresh to see what new content you’d need to commit), a nice custom merge and diff tool, etc.

Are these are good enough reasons to keep it for my everyday work ? No sure yet.

I did encounter a few problems and solving these problems meant dropping to the command line. E.g. : how do you "correct" a rebase that’s stalled… and won't abort nor continue ? hmmmm...  

Were these problems due to the fact that some commands/actions aren’t transparent enough in terms of their effect and the parameters used (e.g. : rebasing… Still confusing… Much more than just using the command line IMO) and so I did some really stupid things? Maybe. Or is it because I was using 2 GUIs at once ? Not sure.

The manual is ok, but not as clear as Tortoise’s, IMHO. Very dry, almost no graphs… and so it remains slightly abstract. I’d almost rather read Git’s man pages (not bad at all btw). I hope they’re going to rework the manual a bit.

That said, I’ll keep an eye on it’s development… and maybe even use it. It’s the most promising solution IMO.

What I’d love SmartGit to integrate in future releases (apart from "blame", "stash", "bisect", etc. support) is :

1- some kind of optional “console like” textual feedback, some commands log view, like the one Git extensions provides (see #4). That would be good (maybe is that a secretly available option but… I didn’t find it).

2- an explorer shell extension.

Note : if you don't use it commercially, SmartGit is free.


 3. TortoiseGit

TortoiseGit is good, but not perfect either... The UI feels a bit scattered and it's certainly not as sexy as SmartGit, but it seems to offer slightly more options overall (bisect, patch creation, blame, stash, etc.) -- however it misses an important one (in relation to the Git index) : staging, which the basic Git GUI do nicely. And, well, it’s got the famous icons overlay. (Not that useful, but still nice to have — I did notice though that it can slow down folder navigation to a crawl… I solved that by killing/restarting the icon cache process)

Detail : I think I found the Tortoise rebasing Gui slightly more intuitive than SmartGit's. But there are other (minor) annoyances, like the ugly graph log.

Performance is "ok" (e.g. : quicker than Git Extensions — see below). Plus, the manual is pretty good (a bit better than SmarGit like I said).

But… I did run into problems using it too. E.g. : when I tried cloning a repo to a bare one, I got an “Unsolvable error”… which I fortunately resolved easily through the command line.

Keyboard usage/navigation (shortcuts, “configurability”…) isn’t that bad either. Not perfect, MUCH better than TortoiseHg (not hard to do)…  But not as Good as SmartGit. I wish I could easily reconfigure the shortcuts to my liking.

“Transparency of action” isn’t great : same “criticism” as SmartGit : some optional pedagogical console-like textual feedback about commands and their options would be good.

A good free overall solution with a few weird things here and there.


 4. Git Extensions

While it looks unfinished (e.g. : many missing icons in the menus), Git Extensions is still pretty nice and in active development. It also integrates with Visual Studio.

What I like the most about it is its mixture of relative completeness and friendliness : it implements a lot of Git commands in an understandable format.

I haven’t done a feature for feature comparison, but it also seems that there are even more implemented Git commands than in TortoiseGit or SmartGit. It really allows the user to do pretty advanced operations right from the user interface (like bisect, stash, and sub modules management).

Like I said, it’s pretty intuitive (if you already know Git a bit), the interface is nice (e.g. : graph log looks MUCH nicer than TortoiseGit's horrible one) and it usually shows you what happens in the background when you choose an option : commands line feedback as text, viewable log of past commands, etc. That, I like a lot ! Git Extensions becomes almost a pedagogical tool (i.e. : you learn knew commands and options by using the GUI).

Git Extensions also provides an easy way to configure the whole Git environment: the editor/ the diff and merge tools, SSH connection, etc.

The Keyboard shortcut config is still rudimentary, but the UI for it is there and it looks like it’s going to be expanded.

So... Overall, it’s pretty well done, even if there are still a few bugs (e.g. : the stash dialog kept the stash content visible even when it had been “dropped” or “popped”… this happened only once though.), and the sluggishness (the main problem IMO).

I won’t go into more details here as I’d repeat stuff I already said.

Would/will I use it ? Yes, but the sluggishness make me prefer Tortoise.


================

GUI CONCLUSION ??? None yet, I’m afraid…

Do I have suggestions ? Probably...

- Maybe try sticking to Git GUI and the command line at first.
- Then, try the other GUIs depending on your needs :
---> Need friendliness, “stand alone” polished app feel, speed, clarity/Flexibility of UI and most important features for everyday Git usage? Go for SmartGit first.
---> Most advanced options and a "pedagogical twist" ? Try Git Extensions first.
---> Extended explorer integration + a bit of all the previous stuff (relative friendliness, advanced options and pretty good performance)? Try Tortoise Git.

Want everything ? Use them all. But be careful...

So… What to *I* currently use ? I was first mostly on SmartGit, then a combination of the command line + Git GUI and Tortoise. But I must say I also used some of Git Extension config tools (Like the SSH configuration dialog).

The fact that I’m often browsing my repos, mean that those with shell extensions tend to be used more…. Which excludes SmartGit for the moment, but favors Git GUI and Tortoise Git.

The story remains open. I haven’t completely made up my mind… "Ultimately", it doesn’t matter that much, really: all of these manipulate the same thing : Git.  And, yes, I’ve decided to use Git instead of Hg. I’ll give some of the reasons in the sequel. I'm tired now.

[2011 03 15 -- 20 48 : Modified the format for better readability. Added a comment about TortoiseGit and its inability to stage before committing ... unless I missed something.]

Nice that you're continuing with this - appreciated

You're welcome.

I still don't have a definitive favorite wrt. GUIs. TortoiseGit, gitk and git-gui all feel a bit rough around the edges. I'm not sure exactly what it is, probably the overall combination of several smaller flaws ("mid 90's linux GUI look", progress not always updated before the command is done (related to calling git.exe and parsing textual output?), et cetera).

I agree. Except for SmartGit maybe, they all feel a but rough. Yes, it is a combination of several factors : look, responsiveness and speed, etc.

Sometimes the UI feels a bit scattered. I find this is especially true with Tortoise Git.

PS: "The sluggishness is probably" -> ends mid-sentence.

Thanks. I'll have to re-read the whole thing as it was pretty late when I wrote it!

(Modified the format of previous long posts for better readability. Added a comment about TortoiseGit and its inability to stage before committing ... unless I missed something. I must say that this is a feature I enjoy using with Git GUI : select all the lines/changes you want to stage (i.e.: put in the index) in the different files, and commit)

I follow this thread with great interest, but lack of time got me never further than actually using the software.

So keep up the good work!  

Thanks. What I hope : that my hours of explorations can benefit others.

I do have a question though: I assume it is possible to search for a particular change by a particular user using any of the GUI tools?
(the lack of that option is something I absolutely hate from WinCVS / CVS (which I am forced to work with).)

Yes it is. It's one of the powerful thing both Hg and Git can do. But Git can even go a step further and actually show you where that change comes from... e.g.: if lines have been from one file to another.

I planned to talk about it with more precision in another post (don't have enough time right now...) but I can briefly touch on the subject.

In Git, you can look at a file and see where everything comes from using that command and options :

git  blame  -C  somefile

I tried the blame function in Mercurial (the same commands available : hg blame -f  somefile, hg annotate -f  somefile ) and it “works” : it tells you who committed a specific line(s), but doesn’t do the impressive thing Git does here:  telling you in which file it was before! IMO, this is no small advantage.

With all the GUIs mentioned above, you can access the basic "blame" command, no problem. But I don't think that they give you the extra option to also see the actual details of "the last file where the moved lines could be found" (I'll double check that later). But you do see the commit's author, hash, etc.

Except for SmartGit, they pretty much have the same work flow. The GUI is different though (tortoise's is nicer and friendlier, but Git GUI (the default) gets the job done too...)

Git GUI :
-select file  
- explorer context menu : Blame

TOrtoiseGit :
- select file  
- explorer context menu : Blame

etc.


Great stuff...

Regarding some SmartGit functionality...

not having an option to use the system JDK but installing it's own separate copy.

Currently there is something like the following bit in section 5.4 of the bundled file quick-start-guide.pdf:

5.4 JRE search order (Windows)
On Windows, the smartgit.exe launcher will search for an appropriate JRE in the following order (from top to bottom):

• Environment variable SMARTGIT JAVA HOME
• Sub-directory jre within SmartGit’s installation directory
• Environment variable JAVA HOME
• Environment variable JDK HOME
• Registry key HKEY LOCAL MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

I haven't personally tested this functionality though as I'm currently trying the portable installation (it comes packaged with a JRE).

I think this topic is awesome. I've got little to offer - except that I barely limp by on my own using git for my personal versioning of my projects. Plain stage, commit -m and tag are all I use - and occasionally Git GUI to rollback a bit. I ought to use branches more, but last time I did so while branching from a public repo, I had a lot of troubles integrating changes made to the public repo into my own branch. Manually needing to merge my months old changes each time pretty much made me drop that hobby activity.

I love the pointers towards the software packages you've put up there - I might need to try those at some point as the command-line does get a bit annoying at times (especially when dealing with files in sub-directories). You found yourself another reader who patiently awaits new additions to this topic!

Thanks Armando, for your continued efforts 

As the topic of the index / staging area in Git is being touched upon, perhaps the following two extensions in Mercurial might be of interest:

  http://mercurial.selenic.com/wiki/RecordExtension
  http://mercurial.selenic.com/wiki/CrecordExtension (demo video)

The record extension provides the record command, which may be used in lieu of commit. This command lets you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks.

The crecord extension is a curses (i.e. text-based GUI) interface which provides the crecord and qcrecord commands that may be used in lieu of commit or qnew -f. These commands let you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks or lines.

I've used both and much preferred the crecord extension experience (see video link above for a sample).  There were a few times when crecord didn't seem to take note of some things I wanted committed -- but perhaps this has been fixed by now as it has been over half a year since I used Mercurial.

At:

  http://kevin-berridge.blogspot.com/2011/04/mercurial-record.html

I encountered the following:

sometimes you forget to be proactive about separating your changes and then you want to untangle them after the fact.  You can do this using the Record extension.  This is another extension that ships with Mercurial, but you have to enable it to use it.

The Record extension is invoked with "hg record" and will go through the files you've changed (or just the ones you tell it to look at) and will iterative over each change "hunk" in the file.  A change hunk is a set of sequentially changed lines.  For each hunk it asks you if you want to record the change or not.  You simply say "y" if you want it, and "n" if you don't.

The result is a new commit that contains the changes you recorded.  It's a surprisingly easy process.

However, there's a flaw with this approach.  The resulting commit might be broken: it might not compile, or the tests might not pass.  And since it turns directly into a commit, you don't really get the chance to test it...

There's also the MQ extension (Mercurial Queue). I remember liking MQ a lot.

This looked interesting to me, but I never tried it out.  Perhaps some day...

I don't have the time to discuss that in depth, but I also remember that I found it easier to work with the "index" like features in Git using the GUI (Git GUI), than with Mercurial (Tortoise Hg). Things are changing fast though and I'll revisit tortoise Hg in a while to see how it does this whole "partial commit" thing.

Looking forward to nicer UIs

Perhaps I'll try out gitsum for Emacs in the mean time:

  http://chneukirchen.org/blog/archive/2008/02/introducing-gitsum.html

BTW, any thoughts on the likes of:

  http://nvie.com/posts/a-successful-git-branching-model/