Re: [VOTE] git versus mercurial (for DragonflyBSD)

[Arne Babenhauserheide <arne_bab@web.de>]

[-- Attachment #1: Type: text/plain, Size: 4084 bytes --]

Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:
> AFAIK Git mostly follows BitKeeper UI; it is quite natural as it was
> meant as replacement for BitKeeper for Linux kernel development.

It is a great choice for an SCM intended for kernel development where everyone 
knows bitkeeper, but might not be optimal for other tasks. 

> Besides is writing plugin in Python for Mercurial that much easier
> than writing new command or stuff in C for Git? Well, perhaps it is,
> as only recently there began to appear API documentation, and there
> were created utility mini-libraries like strbuf, or string_list,
> or parseopt.

Yes, for two main reasons: 

1) Writing Python is much easier and quicker than writing C, especially when 
you can just experiment with the Python interpreter (or better still: with 
ipython). No memory management hassle, no strange compiler bugs, no stray 
pointers. Just plain writing what you want to do. But if you need C speed, you 
can still include parts written in C - where you really need it. For all other 
cases you have more readable and far more compact code. 

2) You can easily access every core function, and you can replace every 
command. 
You don't have to invent a "git foolog" command. Instead you can just adapt 
the regular log to do a foolog which people can use via "hg log". 

> Also often third-party projects or stuff in contrib gets incorporated
> into git proper; sometimes stuff is moved from git core to contrib,
> if there is no maintainer however (git-svnimport, git-p4import).
> Git repository has many roots: one from git core, one with gitk
> (graphical history viewer), one from what was git mail tools, one
> with gitweb (web interface), and one with git-gui (graphical commit
> tool).

Maybe I should include the extensions in the codeswarm to have matching 
repositories. 

> The extending via plugins idea used by Mercurial, so succesfull IMHO
> for Firefox, and I think quite successfull for ikiwiki for example, is
> not without drawbacks, especially that there is no plugins clearinghouse,
> and plugins are required for what is considered pretty required
> functionality, like bisect before hg 1.0.

But they can just be included in the core distibution once they become central 
enough. 

It's a way of allowing people to add functionality they miss without forcing 
them to mess with core code instantly. 

> See also blog post on vcscompare: "Plugins In Version Control"
> http://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html

I just read it, and it didn't convince me, because in my opinion a VCS has 
certain core functions which it should provide to everyone, and other 
functionality which only certain people need. 

For example I normally don't need rebasing, mercurial queues, transplanting 
and similar. Why should my tool include the commands by default? 

The defaults should be the most common way to use the tool, so people can 
easily learn it. 

Advanced stuff can be added with extensions. 

And because the most used plugins are distributed with Mercurial, I can also 
activate them when I don't control the Mercurial installation - and should 
something be missing which I need, I can just download and activate a plugin 
without having to compile anything, since they are simply Python modules. 

Just set 
[extensions]
foo = /blah/foo.py

in ~/.hgrc and the foo plugin is active. 

Gits missing plugin system might just be a reason, why its usability still 
suffers from many problems: They have to do everything for everyone all the 
time, so the chances are high, that they won't do it really good for anyone 
(but the main git coders). 

Best wishes, 
Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]