Main Area and Open Discussion > General Software Discussion
DVCS ? (All about Git, Mercurial-Hg and the like...)
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)
--- End quote ---
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."
--- End quote ---
However, there's also this part :
Some git commands may automatically run git gc; see the --auto flag below for details.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
... :)
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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.selenic.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
--- End quote ---
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.newsupaplex.pp.ru/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... 8)
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.]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version