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

[Jakub Narebski <jnareb@gmail.com>]

Dnia poniedziałek 27. października 2008 21:48, Arne Babenhauserheide napisała:
> Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:
 
> > 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. 

In Git you can write in C, using (underdocumented) git API, or you can
script (in shell script, in Perl, in Python, in Ruby) using git plumbing
commands which are meant for scripting (or bindings in appropriate
language).
 
Most new features, like git-remote tool to manage interaction with
multiple remote repositories, each of which can have multiple branches,
start as a shell or Perl script, and when they and their UI mature they
get converted into C (made into builtin). Builtinification is done not
only for performance, but also for portability (think Perl support on
MS Windows).

So in Mercurial you can write in Python, or you can write in C; in Git
you can write in any scripting language (e.g. shell script, Perl, Tcl/Tk),
or you can write in C... yes, I know it is oversimplification...

> 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".

Well, if I remember correctly if you drop git-foo in EXEC_PATH, then
you would be able to call it as "git foo". So adding commands is easy.

Git provides a few entry points which can be used to extend
functionality. They are: hooks system; gitattributes to define custom
merge, diff and clean/smudge (checkout) drivers per file (pathname);
custom merge strategies; EXTRENAL_DIFF and EXTERNAL_GREP.

I'm not sure if other messing with core functions is a good idea to
have such ability accessible.

> > 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. 

Having some extensions blessed to be included with core program (like
ikiwiki with goodstuff, and similar to Git with contrib/ section)
solves some problems of relying on extensions for basic functionality.
I for example consider bisect and patch+mail workflow tools to be basic,
while patch queue management (well, patch management in general) to be
something that can be built on top of SCM, like StGit, Guilt, TopGit
for Git, or mq (Mercurial Queues) for Mercurial.
 
>
> It's a way of allowing people to add functionality they miss without forcing 
> them to mess with core code instantly. 

The problem with extensions IMVVVHO is that they don't require to
follow strict "inclusion in core" standards, which means that there
is no pressure to add them to core... which for example leads to
including bisect in core only since hg v1.0, "because it is available
as extension".

Requiring to use large amount of extensions to having required
functionality is also one of bad consequences of extension based
development, although having default set of extensions that can be
turned on via some metaextension / metapackage (like ikiwiki's
goodstuff) reduces impact of this.
 
Extensions / modules / plugins are good in projects with high
barriers of development, like Mozilla / Firefox, GNU Emacs, etc.
but I am not sure if it doesn't make for slower core development...

> 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). 

Well, Git doesn't have plugin system, but is easily scriptable...

And, at least according to annual Git User's Survey results (on git wiki)
many people create their custom scripts and scriplets to make their work
with SCM easy...

-- 
Jakub Narebski
Poland