Re: start of git2 (based on libgit2)

Jeff King [off-list ref] writes:

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

quoted

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

I agree that for a summer student project, aiming at basic stuff makes
more sense than trying to chew a large bite that cannot be managed within
the timeframe and not achieving anything.

"A..B" requires you to walk the ancestry chain. Limiting history with
pathspec while simplifying merges needs to use the tree-diff machinery;
and filtering commits by looking at the message with "--grep" needs to
call into the grep machinery.  Depending on how much libgit2 has already
covered the basic blocks, even the above list might be too much, I am
afraid.

A good news is that among the larger and more important basic building
blocks in C git, there is only one part that was designed from day one to
disregard the reusability and instead aimed for speed and simplicity, and
that is the history and object walking. The way the in-core object pool is
managed and especially the way per-object flags are designed to be used
clearly show that the revision walker machinery can take it granted that
the calling programs are run-once-and-clean-via-exit.

But other major parts are designed to be reusable and I would imagine that
it shouldn't be hard to link with them (or better yet, find counterparts
in libgit2). "diff" machinery below the diffcore layer (i.e. the entry
points "diff-lib.c" calls into, e.g. starting at diff_addremove(), then
running the diffcore machinery with diffcore_std() and finally getting the
result from diff_flush() callchain) and "grep" machinery below the
"grep.c" (but not "builtin/grep.c") are designed not to depend on the
process level global variables.

I agree that for a summer student project, aiming at basic stuff makes
more sense than trying to chew a large bite that cannot be managed within
the timeframe and not achieving anything

If things will be working out, I will at least not disappear after the 
summer. I'm quite new here, but I'd like to help out in coordinating the 
student(s) and to continue with it after summer (if the student(s) do 
not stick to the git development). I'm still missing quite some 
knowledge about git, but I hope that will come with time.

"A..B" requires you to walk the ancestry chain. Limiting history with
pathspec while simplifying merges needs to use the tree-diff machinery;
and filtering commits by looking at the message with "--grep" needs to
call into the grep machinery.  Depending on how much libgit2 has already
covered the basic blocks, even the above list might be too much, I am
afraid.

Yes, it would be important to understand how much already is covered by 
libgit2. If someone could shed some light on this (see also my message 
on the libgit2@librelist.org mailing list).

A good news is

[..] still re-reading this paragraph to find out what the actual 'good' 
part of this news is ;)...[..]

that among the larger and more important basic building
blocks in C git, there is only one part that was designed from day one to
disregard the reusability and instead aimed for speed and simplicity, and
that is the history and object walking. The way the in-core object pool is
managed and especially the way per-object flags are designed to be used
clearly show that the revision walker machinery can take it granted that
the calling programs are run-once-and-clean-via-exit.

That's what I meant with my previous message. I was not aiming to 
implement all exotic features, but I think that it would be a good 
design if git and git2 share a lot together and only differ in how they 
actually use the git/libgit backend. As part of the process, the git 
code can be adjusted as well to "libify" it (as it was called in another 
thread).

Vincent