<div dir="ltr">As a test for my "git-fat" extension, I liberated the large files from PETSc's history (managing them outside the repository so that they need not be fetched by everyone; though if you fetch them, the working tree behaves identically to if they were in the repository). This brings the git version of the PETSc repository down to 50MB, and the clone takes 12 seconds:<div>
<br></div><div><div>$ time git clone git@bitbucket.org:jedbrown/petsc-git-lean                                                                                            </div><div>Cloning into 'petsc-git-lean'...</div>
<div>remote: Counting objects: 297100, done.</div><div>remote: Compressing objects: 100% (67974/67974), done.</div><div>remote: Total 297100 (delta 228357), reused 297100 (delta 228357)</div><div>Receiving objects: 100% (297100/297100), 41.22 MiB | 8.71 MiB/s, done.</div>
<div>Resolving deltas: 100% (228357/228357), done.</div><div>12.105 real   13.472 user   2.000 sys   127.81 cpu</div></div><div><div>$ du -hs petsc-git-lean/.git</div><div>50M     petsc-git-lean/.git</div></div><div><br></div>
<div style>The original repository (not managing anything with git-fat) is 78MB with git. Meanwhile, the hg clone takes 10x longer and is much larger:</div><div style><br></div><div style><div>$ time hg clone ssh://<a href="http://hg@bitbucket.org/petsc/petsc-dev">hg@bitbucket.org/petsc/petsc-dev</a> petsc-dev-hg                                                                           </div>
<div>requesting all changes</div><div>adding changesets</div><div>adding manifests</div><div>adding file changes</div><div>added 25751 changesets with 99594 changes to 10045 files</div><div>updating to branch default</div>
<div>4296 files updated, 0 files merged, 0 files removed, 0 files unresolved</div><div>124.376 real   40.954 user   1.827 sys   34.39 cpu</div><div><div>$ du -hs petsc-dev-hg/.hg</div><div>178M    petsc-dev-hg/.hg</div></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 11:02 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im">On Wed, Jan 9, 2013 at 10:46 PM, Sean Farley <span dir="ltr"><<a href="mailto:sean.michael.farley@gmail.com" target="_blank">sean.michael.farley@gmail.com</a>></span> wrote:<br>

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Jed, you have to realize that you're the only one in this thread that<br>

has been disgruntled with mercurial. Even that random dude that<br>
commented still doesn't like git.<br>
<br>
Yes, yes, git did this light-weight branching first. But, IMHO,<br>
mercurial has done it in a cleaner way. And I'll take cleaner and<br>
better thought out than quick and dirty any day.</div></blockquote></div><br></div>It should be obvious that I started the thread mostly to instigate. I didn't expect the trolling conditions to be so good tonight. ;-D<br>
<br>
However, you'll notice quite a number of rants within our circles on G+ (and at large) from people that used hg for a long time and haven't looked back since switching to git. The opposite is rare to non-existent. In the end, I don't think it's deeply important either way, but a lot of our "peer" projects have recently switched for technical reasons and it's potentially fewer tools to install/systems to remember. Oh, and the git emacs support is so much better.</div>

</div>
</blockquote></div><br></div></div>