DVCS ? (All about Git, Mercurial-Hg and the like...)

[Armando]

I've settled on Git for moving fSekrit forwards, but that's mainly because of Git's "blow off your legs" power with regards to history rewriting - I want to make the codebase public, but retain no memory in the public codebase from the non-public versions. Yet, at the same time, I want the private repository to have FULL history, and do that without committing future versions to both public and private repositories. Git supports that (even if I haven't worked out the details of how to set it up 100% ).

-f0dder (March 04, 2011, 03:28 PM)

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.

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.

History of a single function that moves? Interesting. That's not something inherent in how git stores the version history, though, unless I've missed something - Git stores the full version of each file for each commit, whereas both subversion and Mercurial store changesets (iirc Mercurial also stores a full-version "every once in a while" so moving between versions doesn't become too slow). But IOW, if Git can do it, it's gotta be history analyzing magic smartness that could potentially be done by everybody else too?

-f0dder (March 04, 2011, 03:28 PM)

That's what I read on stackoverflow. Don't take my word for it! I'm going to try to find out more info on that.

From what I've seen from various comparisons, Git and Mercurial offer most of the same features, as long as you don't need the über-wicked geek functionality (Mercurial pretty much won't let you blow your legs off). Also seems like there's not massive speed differences for "normal" size projects.

-f0dder (March 04, 2011, 03:28 PM)

I've seen a number of benchmarks. AFAICT, it varies depending on the task, OS, etc. so it's hard to say. In any case, I'd say that when working locally, we're talking about less than a second. Bazaar has some nice benchmarks numbers on its page, but... I haven't found the same results anywhere else.

Git seems a bit more down and dirty, and the tortoise version still isn't as polished as the tortoise versions of other version control systems... it still shows a bit that Git was originally a whole bunch of shell scripts, instead of designing it "properly" as a C/C++ library with a "proper" front-end

-f0dder (March 04, 2011, 03:28 PM)

I just looked at smartGit and it looks really nice. I'll see if I can play with it during the weekend.

I probably shouldn't but I'm currently looking at Git.

-Armando (March 04, 2011, 03:19 PM)

Oh yes, you should, if you have the time, resources and interest in it.
Making a more educated choice now (early/pre-start) is way better than to change half way through your project, if you then discover a feature in the other solution you absolutely must have, for whatever reason.

-Ath (March 04, 2011, 03:30 PM)

Thanks for the encouragement. I just have to be careful to not spend too much time obsessing about details -- something I'm pretty good at.    But you're probably right. That's why I'll check out the Git option bit more carefully.

I use git with great success, but it does have drawbacks, namely poor support for Windows platform.

It is very fast even with large repositories.

AFAIK mercurial has much wider platform support than git, but is also rather slow. This is from hearsay though.

I chose git at that time because it was the new shit.

-housetier (March 04, 2011, 04:12 PM)

Eheh...
Git effectively seems a bit speedier. But, concretely, I'm not sure if I'd be able to see the difference in my everyday work.

The 'portable Git preview' software (for Windows) you can get from softpedia looks to be very promising.


And together with SmartGit (free for personal use) it starts to look quite nice as well.

One hell of lot better than WinCVS at least  

**EDIT
Added the SmartGit part.

-Shades (March 04, 2011, 04:50 PM)

Thanks Shades. I downloaded both. Will report back.

[f0dder]

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.

-Armando (March 04, 2011, 10:07 PM)

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.

-Armando (March 04, 2011, 10:07 PM)

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

[Deozaan]

Don't forget a nice way to get started with Hg is from http://hginit.com/

I personally use Hg (and http://BitBucket.org/) and I, too, found it easier to use the command line than TortoiseHg.

[Armando]

@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.

- http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/

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).

-http://code.google.com/p/support/wiki/DVCSAnalysis

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/pr...er/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.sel....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...

[f0dder]

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.

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



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.

[Armando]

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.

-f0dder (March 08, 2011, 03:53 AM)

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

-f0dder (March 08, 2011, 03:53 AM)

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.

-f0dder (March 08, 2011, 03:53 AM)

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..]

[f0dder]

Interesting notes on performance!

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).

-Armando (March 08, 2011, 10:50 AM)

Oh, the problems I've had are there even with a single Tortoise flavor installed - dunno if it "stacks up" when there's multiple versions. Happens relatively rarely, but enough that it's a minor annoyance.

[Armando]

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.]

[Armando]

d.   Hg vs Git — GUI support

What about Hg vs Git, in terms of GUI support ?
Well, even though Hg (Mercurial) as such is extremely well supported on Windows, there are a bit less choices than Git in terms of GUIs and, ironically, its “almost default” GUI (hgk Extension) doesn’t even work by default on windows !

 i.   Hg… more about it.

For Hg GUIs one can look at http://mercurial.sel....com/wiki/OtherTools. Many are outdated and their development has either stopped (e.g. : Push Me Pull You, hgct, CuteHg) or slowed down (e.g. : hgview)

     1.   Hgk

Like I just said, I first wasn’t able to use the Hgk Extension (hg view), the graph log viewer + basic GUI functionalities which now comes “by default” with Hg.  Mercurial complained and I had to take more than 30 min to find a proper solution. The terrible instructions on the official page didn’t work. Messy stuff… Then I found these instructions (thanks Mr David P. Caldwell) and I finally got it to work.

I used it a few times and it’s good if you like the command line and only want to have a graph log and other easily accessible info describing where you’re at in terms of commit, etc... So I tested a few other more sophisticated GUIs… The 2 I looked at in more details are TortoiseHg the more “fringy” one HgWin (which BTW is one of the few actively developed) .

     2.   HgWin

HgWin, is now on v1.4.1 since yesterday. It can be used through visual studio or the command line (e.g. : “hgwin log” shows the graph log, etc.). It  looks clean enough and there are more an more features added to it with every new version (i.e. : (more Hg commands implemented).

Features :
•   Support for operations: Commit, Revert, Resolve, Compare, Update, Tags, Push, Pull, Incoming, Outgoing, Merge, Clone, Bundle, Archive, Annotate (Blame), View File, Grep, Bookmarks, Rebase
•   File history dialog with support of file differencing
•   Support tracking of file renames in file history dialog
•   Support external file comparison tools
•   Revisions graph log. This feature is similar to hgk, hgview and tortoiseHg change log window
•   Support for merging revisions
•   Support for rebasing revisions
•   Support for inline file difference in most of package windows
•   Support for bookmarks

-http://www.newsupaplex.pp.ru/hgwin_news_eng.html

Like I said, the developer also makes a visual studio plugin which IMO seems fine enough for most basic operations (but doesn’t support some more advanced features or extensions like Mercurial Queues or Collapse). http://www.newsupapl.../hgscc_news_eng.html.

I found the UI a bit sluggish at times but it gets the job done. The hgwin log command brings up the main log window which can be used to access most of the other features. The “hgwin” command  just brings up a summary of all  commands.

I won't use it much though as for Hg, I prefer TortoiseHg


     3.   TortoiseHg


TortoiseHg is "better" : more polished, more flexible and has more features…  and I won’t go through them as it’s a much  more familiar interface. You have the icons overlay,  it does all basic options well and you can easily add extensions using its interface. It also has a set of command line options if you don't want to leave the command line.


However, I must say that both Tortoise AND HgWin have a not so great keyboard support. I’m very sensitive to that and it annoys me when developers don’t add any shortcuts to access menus, buttons, etc.

This will allow for a nice transition to Git GUIs… As for some mysterious reason, not only are Git GUIs generally better, but keyboard support is better in all of them. No idea why.

[Armando]

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 [I did miss the "stash" command which was very obvious  ] ).

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.]

[f0dder]

Nice that you're continuing with this - appreciated

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).

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

[Armando]

Nice that you're continuing with this - appreciated

-f0dder (March 15, 2011, 03:02 AM)

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).

-f0dder (March 15, 2011, 03:02 AM)

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.

-f0dder (March 15, 2011, 03:02 AM)

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

[Armando]

Here's what I plan to talk about/explore next time (in a few days probably... but that doesn't mean that we shouldn't have other related discussions in between ) :

i. Git's Index
ii. File renaming (indexing/staging corollary)
iii. Code/Txt move detection (related to indexinq)
iv. Branching
v. Merqinq
vi. Other more subtle differences between Hg/Git
vii. Expendability
viii. Collaboration tools
ix. Commands
x. Hosting sites

[Armando]

(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)

[Shades]

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! 

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).)

[Armando]

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!  

-Shades (March 16, 2011, 01:05 PM)

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).)

-Shades (March 16, 2011, 01:05 PM)

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...

[Armando]

I haven't abandoned this thread!  But I'm lacking time these days, so here's an article offering an interesting point of view.

Why I Like Mercurial More Than Git

I don't fully share the author's opinion, but he clearly has more experience with both software than I do.

I'm going to keep in mind his remarks as I continue using Git -- which, as far as I'm concerned, has been a pleasure! Contrarily to the author I find that Git's index is a real strength and it does make a difference in my work.

[ewemoa]

Regarding some SmartGit functionality...

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

-f0dder (March 08, 2011, 03:53 AM)

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).

[Armando]

Thanks for the heads up ewemoa, and also for bringing back this thread to my mind ! 

[worstje]

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!

[Armando]

Cool then! I just wish I had more time to play with Git myself these days. I use it minimally, but I did a few merges etc. successfully. I mainly use git's GUI (the one that comes with Git by default) and tortoise Git these days.

=====

C-   Some Detail about Git’s Index and "Content based" structure

(This is approximately where I left imy thoughts last time, when I answered Shades' question... So I might as well continue from there.)


so... What's the Git index?


Scott Chacon in Pro Git (an excellent manual, which can be read online) explains :

The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.

John Wiegley, in "Git From the bottom Up", writes :

Unlike other, similar tools you may have used, Git does not commit  changes directly from the working tree into the repository.  Instead, changes are first registered in something called the index.  Think of it as a way of “confirming” your changes, one by one, before doing a commit (which records all your approved changes at once).  Some find it helpful to call it instead as the “staging area”, instead of the index.

While I personally love the concept of staging area and the way Git uses it (I'll tell you why after), not everybody does. Steve Losh Writes :

One of the features that git users talk about often is git’s index. Mercurial has the record extension, but it’s not really the same thing.

I personally don’t like the index. I feel that git encourages people to check in changesets that contain code which they’ve never tested (or even built) because the index is such a prominent part of git’s workflow.

Yes, one can argue that you don’t actually push changes until you’ve got a working state. The problem is that when you then try to run git bisect later to find a bug you’ll have to waste time skipping over changesets that don’t build. You could use git rebase --interactive to fold partial changesets into one big one, but again, my gut feeling is that few people actually bother testing the results.

-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/

I'm not an experienced programmer, but  I think that the staging area (index) is very useful. I use it all the time as it's very convenient when you need to group similar changes together. I.e. : if you worked a while without committing anything, you can decide to commit your work in parts using the staging area. Of course you run the risk of having a few commits that won't compile, but then, as M. Losh says, you can just do a "git rebase --interactive to fold partial changesets".

What's telling is what Losh says afterward:

With all that said, I’ve considered creating a Mercurial extension that adds git’s index functionality to Mercurial, because I think it would make the transition to Mercurial easier for git users. I’ve had enough experience with Mercurial’s internals to know that such a thing is possible, but I simply don’t have the time to do it all myself. If you’re interested in helping out please let me know!

-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/

...  So maybe this index isn't that useless after all.

Not all GUIs out there allow to granularly add parts of file changes to the index. The “vanilla” Git GUI allows it very easily (select part of the code you want to “stage” and add them to the index; when you’re finished, commit the whole thing).

While I now realise it's probably not as related as I first thought it was, Git's use of an index is still coherent with the way it keeps track of files changes by storing content, not files.

In "Git Internals", Scott Chacon writes :

It is important to note that it is the contents that are stored, not the files. The names and modes of the files are not stored with the blob, just the contents.

This means that if you have two files anywhere in your project that are exactly the same, even if they have different names, Git will only store the blob once. This also means that during repository transfers, such as clones or fetches, Git will only transfer the blob once, then expand it out into multiple files upon checkout.

This "content driven" structure (if I may say so) has 2 implications I'll try to write about next time -- I'm already late for my next meeting !

[ewemoa]

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.sel...wiki/RecordExtension
  http://mercurial.sel...iki/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-berridg...ercurial-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...

[Armando]

Thanks ewemoa  .
the Record and Crecord Mercurial extensions definitely allow a similar workflow.
There's also the MQ extension (Mercurial Queue). I remember liking MQ a lot.

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.

[ewemoa]

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

-Armando (May 10, 2011, 10:01 AM)

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/

[Armando]

I haven't forgotten this discussion... 

I'm just lacking time these days !...  But I plan to continue to contribute to this thread with reflections about Git and Mercurial's various aspects -- although I'm more focused on Git, since this is the tool I chose. (Did I mention earlier that I not only decided to use Git because I like it but also because is my various tests it was easier to convert a Git repo to Mercurial than the reverse ?  )

=====

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

  http://chneukirchen....roducing-gitsum.html

Cool stuff. I'll have to check that out.

BTW, any thoughts on the likes of:

  http://nvie.com/post...git-branching-model/

Branching is an interesting topic. It's good to see the different strategies used among developers. I saw the article you're referring to a few weeks ago.

The problem is that in my own current project, I don't really need to "branch" that much. It's just not worth it. So I haven't explored that area a whole lot. I've read about it though.