Re: libgit2 - a true git library

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 31, 2008, 23:49 UTC
Message-ID: <7v63n872bs.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081031232829.GC14786@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> You are the end-user of the library, so it needs to suit you.  Ok,
> you aren't the only end-user, but you and other developers like
> you... :-)

I will be the end-user of the library because if we want libgit2 to be anywhere close to successful, you should be able to port C-git to it.

I understand that the apidocs/ is a very early work-in-progress, but still, it bothers me that it is unclear to me what lifetime rules are in effect on the in-core objects. For example, in C-git, commit objects are not just parsed but are modified in place as history is traversed (e.g. their flags smudged and their parents simplified). You have "flags" field in commit, which implies to me that the design shares this same "modified by processing in-place" assumption. It is great for processing efficiency as long as you are a "run once and let exit(3) clean-up" type of program, but is quite problematic otherwise. commit.flags that C-git uses for traversal marker purposes, together with "who are parents and children of this commit", should probably be kept inside traversal module, if you want to make this truly reusable.

By the way, I hate git_result_t. That should be "int", the most natural integral type on the platform.