Re: start of git2 (based on libgit2)

[Jeff King <peff@peff.net>]

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