Gwern Branwen wrote: > I too have cast an avaricious eye over gitit. I am unsure that we need > libdarcs, however. Take a look at the module which handles the actual > Git integration for gitit: > http://github.com/jgm/gitit/tree/master/Gitit%2FGit.hs > > It is basically 10 functions which are not much more than > shell-scripting. Most of them look like they could easily be replaced > by Darcs equivalents. The only ones that look really different are the > ones which use the SHA1 identifiers, and presumably for Darcs that > would be replaced by simply the name of a patch.
No, you probably want to use the patch hashes (from darcs changes --xml-output; darcs x --match="hash ..."). I do think that all of these functions could be implemented with the existing command line interface, with perhaps a possible exception of gitGrep (use real grep instead? temporary repositories may be a concern?). On the other hand, if people really are desperate for a libdarcs approach (git seems fine in this example without a libgit), I think this could serve as a good minimal case to begin with for a libdarcs0: 1) It just needs to export to Haskell code. 2) There is a very small subset of necessary API calls, most of which already exist at the CLI/command/subcommand level. 3) It will be immediately usable by an implementing third party application that can serve as the benchmark/proof-of-concept. It seems better than "export everything and close/deprecate features as we see fit" to go "start with an existing app(s) and add features as feedback comes in". Ultimately, however I think worrying about libdarcs in this case is a red herring: the first focus should be performance. Given CLI commands that run nearly as fast as their git counterparts is probably more useful to everyone involved (even with shell-scripting interop/marshalling concerns). -- --Max Battcher-- http://worldmaker.net _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
