Re: libgit2 - a true git library

[Junio C Hamano <gitster@pobox.com>]

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