newbie questions about hg and git design and features

[Benoit Boissinot]

On 1/30/07, Mike Coleman <tutufan at gmail.com> wrote:
> [Also sent to the git list.  --Mike]
>
> Hi,
>
> I recently decided to jump into the DVCS pool, and I've been studying
> what seem to me to be the two leading candidates--git and
> mercurial--to try to understand the differences between them in design
> and features.  I have some questions that I hope you can enlighten me
> on.
>
> 1.  As of today, is there any real safety concern with either tool's
> repo format?  Is either tool significantly better in this regard?
> (Keith Packard's post hints at a problem here, but doesn't really make
> the case.)
>
About Keith's post you can have a look at Matt's reply to those
concerns [1]. In short, hg has a quite clever repository format with
O(size of files) retrieve and commit complexity and safe append only
commit. The wiki page 'Design' has more details as well as the slides
from Matt's talk.

> 2.  Does the git packed object format solve the performance problem
> alluded to in posts from a year or two ago?
>
> 3.  Someone mentioned that git bisect can work between any two
> commits, not necessarily just one that happens to be an ancestor of
> the other.  This sounds really cool.  Can hg's bisect do this, too?
>
I never really used git bisect, but hg bisect should work the same (it
operates on the DAG of changesets), it has a little bit less features.
(I should find the time to implement path restriction and
'do-not-compile' revs).

> 4.  What is git's index good for?  I find that I like the idea of it,
> but I'm not sure I could justify it's presence to someone else, as
> opposed to having it hidden in the way that hg's dircache (?) is.  Can
> anyone think of a good scenario where it's a pretty obvious benefit?
>
I never really understood why git doesn't hide the index (we call it
dirstate in hg).
In hg the following commands modify the dirstate:
add/remove/rename/revert, they are just high level and perhaps more
intuitive.

> 6.  Does either tool use hard links?  This matters to me because I do
> development on a connected machine and a disconnected machine, using a
> usb drive to rsync between.  (Perhaps there'll be some way to transfer
> changes using git or hg instead of rsync, but I haven't figured that
> out yet.)

Hg uses hardlinks when you locally clone repositories.
>
> 7.  I'm a fan of Python, and I'm really a fan of using high-level
> languages with performance-critical parts in a lower-level language,
> so in that regard, I really like hg's implementation.  If someone
> wanted to do it, is a Python clone of git conceivable?  Is there
> something about it that just requires C?
>
By the way we will soon add pure python/C implementation of patch.

> 8.  It feels like hg is not really comfortable with parallel
> development over time on different heads within a single repo.
> Rather, it seems that multiple repos are supposed to be used for this.
>  Does this lead to any problems?  For example, is it harder or
> different to merge two heads if they're in different repo than if
> they're in the same repo?
>
it is the same, to merge two heads you have to first get it in your repo:

hg pull other_repo
# hg heads will show two heads
hg merge

regards,

Benoit

[1] http://www.selenic.com/pipermail/mercurial/2006-November/011678.html