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:
signature.asc
Description: This is a digitally signed message part.
