Main Area and Open Discussion > General Software Discussion
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
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/
--- End quote ---
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
--- End quote ---
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... :)
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version