On Sat, Mar 26, 2011 at 12:54:25AM +0100, Vincent van Ravesteijn wrote: > http://librelist.com/browser/libgit2/ > >According to Jeff King[2], I should start with plumbing commands. I > >agree. However, how deep? I.e. do I have to make sure all git rev-list > >possible arguments are implemented? > > I guess a lot can be copied from Git itself. Actually > builtin/rev-list.c consists mostly of command line arguments parsing > methods, and outputting functions. The key is to parse what you want > to know and ask libgit2 to provide the info. If libgit2 has > implemented the basic functionality that is needed, the rest would be > relatively simple. I wouldn't worry about having _every_ argument. Some arguments are much less frequently used than others. For example, start with basic stuff, like including and excluding commits (e.g., "branch1 ^branch2"), --max-count, --{min,max}-age, --grep, and others. Do common things like path limiting. And then once all that is done and tested, start worrying about things like --cherry-pick (or maybe not, and focus on the basics of other simple commands). > >Are we aiming for a distributed 100s of executables architecture > >(current git), or single huge binary? I would go for single executable > >for to higher portability. Is that ok? > > AFAICS, current git is a single binary on Windows already. Even on Linux, most of the commands are just hardlinks to the git executable. Most commands are built-in these days. A few are still external but written in C (sometimes because we want to keep them small and external, like git-daemon and git-shell). But there are still some commands written in other languages, like pull, stash, and add--interactive. Check out the BUILTIN_OBJS, PROGRAM_OBJS, and SCRIPT_* variables in the Makefile. So yeah, for basic commands, one monolithic binary is probably fine. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html