Re: start of git2 (based on libgit2)

On Sat, Mar 26, 2011 at 12:54:25AM +0100, Vincent van Ravesteijn wrote:

http://librelist.com/browser/libgit2/

quoted

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

quoted

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