Re: linking libgit.a in C++ projects

["Sverre Rabbelier" <alturin@gmail.com>]

On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
> Using output from the command line utilities as an API has its own set
> of problems. For instance, check out some of the difficulties that
> gitk and qgit have had to deal with:
> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.

I beg to differ. If I skimmed the topic correctly, the problems there
were not related to having to parse git's output, but due to the fact
that '--topo-order' is a post-processing operation, which takes long.
Do read the recent discussion between Linus and Roman about that.

> Digging into
> the git internals and reusing its core functions will always be more
> powerful and flexible than parsing command line output.

Sure, but is it worth it? What do you need in your GUI that you cannot
get from the plumbing?

> Of course, it
> is not always easy; git wasn't written to be easily compiled into a
> library and reused (graceful error handling and memory management are
> problematic). But I think the right thing to do is to work towards
> making the awesome git internals easier to use for other developers so
> great tools can continue to be built on top of git.

I do agree with that, libification of git would be really nice.
Especially since that'd mean that integrating it into other languages
(by means of wrappers), such as Python or Ruby, becomes a lot easier.

>> There is, use the plumbing, forward compatibility is 95% assured. With
>> the exception of major releases, for which any plumbing
>> output/behavior changes will be announced in the changelog, usually
>> including an explanation on how to change your code to match.
>
> 95% assured != correct, IMO :)

Why not? Junio has a very good reputation of keeping git backwards
compatible. The 95% is of course not an actual figure but an
expression meant to indicate "statement is true, minus a few rare case
exceptions".

>> In short, use the forc-... errr, plumbing ;).
>>
>> --
>> Cheers,
>>
>> Sverre Rabbelier
>>

It's ok to remove text that you do not respond to, including signatures :P.

-- 
Cheers,

Sverre Rabbelier