linking libgit.a in C++ projects

classic Classic list List threaded Threaded
26 messages Options
12
cte
Reply | Threaded
Open this post in threaded view
|

linking libgit.a in C++ projects

cte
I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
than being lame and parsing the output the various git commands, I'm
using libgit.a to provide all of the needed functionality for my app.
However, the git source uses a few reserved C++ keywords; namely
'typename', and 'new'. So, I was wondering if it is worth submitting a
patch to fix these issues... I'm asking because I'm new to the whole
open source thing, and I don't want to get yelled at by the git
maintainers for submitting stupid patches that no one in their right
mind would accept :)

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Dmitry Potapov
On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
> than being lame and parsing the output the various git commands, I'm
> using libgit.a to provide all of the needed functionality for my app.

Don't do that! libgit.a is an internal library used solely to build
git binaries. It means that its interface can be cahnged at any time.
Though, there is an idea of creating the real git library that other
applications can use, but AFAIK no one is working on it. So parsing
output is the only correct solution right now. In fact, it is not
difficult to do, because most plumbing commands are rather flexibly
in what they output and how.

> However, the git source uses a few reserved C++ keywords; namely
> 'typename', and 'new'.

Because this source code are meant to be compiled by C and not by C++!
Even if we will have real git library for other applications to use,
it still be compiled only by C. Thus, C++ keywords are not issue.

Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
cte
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

cte
On Thu, Jul 31, 2008 at 3:57 AM, Dmitry Potapov <[hidden email]> wrote:

> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
>> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
>> than being lame and parsing the output the various git commands, I'm
>> using libgit.a to provide all of the needed functionality for my app.
>
> Don't do that! libgit.a is an internal library used solely to build
> git binaries. It means that its interface can be cahnged at any time.
> Though, there is an idea of creating the real git library that other
> applications can use, but AFAIK no one is working on it. So parsing
> output is the only correct solution right now. In fact, it is not
> difficult to do, because most plumbing commands are rather flexibly
> in what they output and how.

I'm not worried about the interfaces changing; the gui is tied to a
particular version of git, and I will update the code that calls into
libgit I pull new changes from the mainline into my local clone. Also,
who's to say that the output of the various commands won't change
formats with future releases of git? There is no correct solution if
you are worried about forward compatibility, unless a well defined API
is created (which would be sweet btw, but is probably not a priority).

>> However, the git source uses a few reserved C++ keywords; namely
>> 'typename', and 'new'.
>
> Because this source code are meant to be compiled by C and not by C++!
> Even if we will have real git library for other applications to use,
> it still be compiled only by C. Thus, C++ keywords are not issue.

Clearly ;)

Fortunately, g++ can compile C programs and link static libraries that
were compiled by C compilers, unless of course, they use C++ keywords.
I don't think it is unreasonable to rename the _very few_ C++ keywords
in git's source in the interest of allowing C++ projects to leverage
libgit.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Petr Baudis
In reply to this post by Dmitry Potapov
On Thu, Jul 31, 2008 at 02:57:27PM +0400, Dmitry Potapov wrote:
> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
> > I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
> > than being lame and parsing the output the various git commands, I'm
> > using libgit.a to provide all of the needed functionality for my app.
>
> Don't do that! libgit.a is an internal library used solely to build
> git binaries. It means that its interface can be cahnged at any time.

I don't think this is that big a problem; there are applications that
are doing this already, e.g. cgit, and if you tie your application to
a particular git version by for example making git a submodule of your
source, this is pretty safe; it will just mean that you will have to
do some non-trivial porting of your code to the new interface each time
you update - but I think large changes in the interface are pretty rare
in practice by now, and there shouldn't be much on the horizon either(?).

> > However, the git source uses a few reserved C++ keywords; namely
> > 'typename', and 'new'.
>
> Because this source code are meant to be compiled by C and not by C++!
> Even if we will have real git library for other applications to use,
> it still be compiled only by C. Thus, C++ keywords are not issue.

What would be the reason to disallow C++ users? The costs aren't that
high, and (modulo, say, extern "C" { }) there should be no C-C++
compatibility issues, right?

--
                                Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Pedro Melo
In reply to this post by cte

On Jul 31, 2008, at 12:10 PM, cte wrote:

> On Thu, Jul 31, 2008 at 3:57 AM, Dmitry Potapov <[hidden email]>  
> wrote:
>> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
>>> However, the git source uses a few reserved C++ keywords; namely
>>> 'typename', and 'new'.
>>
>> Because this source code are meant to be compiled by C and not by C+
>> +!
>> Even if we will have real git library for other applications to use,
>> it still be compiled only by C. Thus, C++ keywords are not issue.
>
[...]
> Fortunately, g++ can compile C programs and link static libraries that
> were compiled by C compilers, unless of course, they use C++ keywords.
> I don't think it is unreasonable to rename the _very few_ C++ keywords
> in git's source in the interest of allowing C++ projects to leverage
> libgit.

I think the point Dmitry was trying to make is that you should compile  
libgit as C, using gcc, and then link it with your C++/Objective C code.

No patch is required to git, only to your makefile/xcode project file.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [hidden email]
Use XMPP!


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
cte
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

cte
In reply to this post by Petr Baudis
> What would be the reason to disallow C++ users? The costs aren't that
> high, and (modulo, say, extern "C" { }) there should be no C-C++
> compatibility issues, right?

Exactly. It works just great for me in XCode 3.1 on OS X.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Petr Baudis
In reply to this post by Pedro Melo
On Thu, Jul 31, 2008 at 12:16:45PM +0100, Pedro Melo wrote:
> I think the point Dmitry was trying to make is that you should compile
> libgit as C, using gcc, and then link it with your C++/Objective C code.
>
> No patch is required to git, only to your makefile/xcode project file.

libgit has a certain (albeit currently unofficial and non-settled) API
and the API is defined in header files that must be eatable by C++
compilers in order to do this.

                                Petr "Pasky" Baudis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
cte
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

cte
In reply to this post by Pedro Melo
>> Fortunately, g++ can compile C programs and link static libraries that
>> were compiled by C compilers, unless of course, they use C++ keywords.
>> I don't think it is unreasonable to rename the _very few_ C++ keywords
>> in git's source in the interest of allowing C++ projects to leverage
>> libgit.
>
> I think the point Dmitry was trying to make is that you should compile
> libgit as C, using gcc, and then link it with your C++/Objective C code.
>
> No patch is required to git, only to your makefile/xcode project file.

The git .h files must be in your include path, and must not contain
C++ keywords in order to link against libgit.a.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Dmitry Potapov
In reply to this post by Petr Baudis
On Thu, Jul 31, 2008 at 01:14:46PM +0200, Petr Baudis wrote:
>
> I don't think this is that big a problem; there are applications that
> are doing this already, e.g. cgit, and if you tie your application to
> a particular git version by for example making git a submodule of your
> source, this is pretty safe; it will just mean that you will have to
> do some non-trivial porting of your code to the new interface each time
> you update - but I think large changes in the interface are pretty rare
> in practice by now, and there shouldn't be much on the horizon either(?).

What you see as large changes depend on how well you know git internals.
Git develops very quickly and if someone who is trying to use libgit.a
does not follow git development closely, it may happen pretty soon that
even not so big changes will become a huge problem to accomadate them.
As result, the program may stick with an old Git version, and that puts
users of this program in the situation where they cannot use their
favorite frontend with new repositories.

> What would be the reason to disallow C++ users? The costs aren't that
> high, and (modulo, say, extern "C" { }) there should be no C-C++
> compatibility issues, right?

I mean that putting  extern "C" { } around should be sufficient to use
this library in C++. But I see now some current headers contains some
C++ keywords and that causes the problem. So, yes, those headers should
be corrected if they become part of external available API. I am not
sure whether it makes sense to correct them now, but there are only
three places where C++ keywords are used:

diff.h:135:extern int diff_tree_sha1(const unsigned char *old, const
diff.h:137:extern int diff_root_tree_sha1(const unsigned char *new,
object.h:38:extern const char *typename(unsigned int type);

So, the patch should not be large, and it is up to Junio to decide
what to do about it.

Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Boaz Harrosh-3
In reply to this post by cte
cte wrote:

> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
> than being lame and parsing the output the various git commands, I'm
> using libgit.a to provide all of the needed functionality for my app.
> However, the git source uses a few reserved C++ keywords; namely
> 'typename', and 'new'. So, I was wondering if it is worth submitting a
> patch to fix these issues... I'm asking because I'm new to the whole
> open source thing, and I don't want to get yelled at by the git
> maintainers for submitting stupid patches that no one in their right
> mind would accept :)
>
> Thanks!
> --

The practice of avoiding C++ keywords from public C headers is
very welcome. You should send a patch and try to push it.

That said the problem can be easily avoided.

Produce a C file and header that defines some stable API to your
GUI application, that does not expose any git internal headers.
Then compile that, say git_api.c, with C compiler in Makefile
and extern "C" link that file to your C++ application. This will
completely insulate you from any git code.

This could also solve the other problem of API changing, only
the git_api.c need change, your outer GUI code stays the same.

And if you do all that maybe you can submit it for inclusion
as a: somewhat stable high-level library, for developers.
Ala git-dev

Cheers
Boaz

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Dmitry Potapov
On Thu, Jul 31, 2008 at 04:04:50PM +0300, Boaz Harrosh wrote:
>
> Produce a C file and header that defines some stable API to your
> GUI application, that does not expose any git internal headers.
> Then compile that, say git_api.c, with C compiler in Makefile
> and extern "C" link that file to your C++ application. This will
> completely insulate you from any git code.

While the idea of creating of such a wrapper makes sense, it may not
easy to implement properly in all cases, because some git functions
do not free allocated memory as they rely on this memory being free
at exit. There is a problem with die() as it is not enough to longjmp
from it, you have to free all resources that were allocated (such as
open files, memory). Thus writing a full functional library, which
will not leak resources, is not an easy task. Of course, some of Git
function can be used easily without risk that your application will
leak resources.

Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Sverre Rabbelier
In reply to this post by cte
On Thu, Jul 31, 2008 at 13:10, cte <[hidden email]> wrote:
> I'm not worried about the interfaces changing; the gui is tied to a
> particular version of git, and I will update the code that calls into
> libgit I pull new changes from the mainline into my local clone.

You should be ;). Unless you are planning to learn a lot of C very
fast, you should be worried about the interfaces changing. That is, if
you want your GUI to be able to stay up to date with the current git
version.

> who's to say that the output of the various commands won't change
> formats with future releases of git?

Junio is to say. Plumbing output format is git's API.

> There is no correct solution if
> you are worried about forward compatibility, unless a well defined API
> is created (which would be sweet btw, but is probably not a priority).

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.

In short, use the forc-... errr, plumbing ;).

--
Cheers,

Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Alex Riesen
In reply to this post by Boaz Harrosh-3
Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:
> Produce a C file and header that defines some stable API to your
> GUI application, that does not expose any git internal headers.
> Then compile that, say git_api.c, with C compiler in Makefile
> and extern "C" link that file to your C++ application. This will
> completely insulate you from any git code.

no, it wont. He still have to resolve name conflicts at the link time.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Avery Pennarun
On 7/31/08, Alex Riesen <[hidden email]> wrote:
> Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:
> > Produce a C file and header that defines some stable API to your
>  > GUI application, that does not expose any git internal headers.
>  > Then compile that, say git_api.c, with C compiler in Makefile
>  > and extern "C" link that file to your C++ application. This will
>  > completely insulate you from any git code.
>
> no, it wont. He still have to resolve name conflicts at the link time.

Language keywords (as opposed to function names) like 'new' and
'typename' are definitely not exported to the object files.  Moreover,
function parameter names aren't either.

Avery
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
cte
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

cte
In reply to this post by Boaz Harrosh-3
Excellent idea; thank you!

> The practice of avoiding C++ keywords from public C headers is
> very welcome. You should send a patch and try to push it.
>
> That said the problem can be easily avoided.
>
> Produce a C file and header that defines some stable API to your
> GUI application, that does not expose any git internal headers.
> Then compile that, say git_api.c, with C compiler in Makefile
> and extern "C" link that file to your C++ application. This will
> completely insulate you from any git code.
>
> This could also solve the other problem of API changing, only
> the git_api.c need change, your outer GUI code stays the same.
>
> And if you do all that maybe you can submit it for inclusion
> as a: somewhat stable high-level library, for developers.
> Ala git-dev
>
> Cheers
> Boaz
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
cte
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

cte
In reply to this post by Sverre Rabbelier
On Thu, Jul 31, 2008 at 11:27 AM, Sverre Rabbelier <[hidden email]> wrote:
> On Thu, Jul 31, 2008 at 13:10, cte <[hidden email]> wrote:
>> I'm not worried about the interfaces changing; the gui is tied to a
>> particular version of git, and I will update the code that calls into
>> libgit I pull new changes from the mainline into my local clone.
>
> You should be ;). Unless you are planning to learn a lot of C very
> fast, you should be worried about the interfaces changing. That is, if
> you want your GUI to be able to stay up to date with the current git
> version.

That is the plan.

>> who's to say that the output of the various commands won't change
>> formats with future releases of git?
>
> Junio is to say. Plumbing output format is git's API.

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. Digging into
the git internals and reusing its core functions will always be more
powerful and flexible than parsing command line output. 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.

>> There is no correct solution if
>> you are worried about forward compatibility, unless a well defined API
>> is created (which would be sweet btw, but is probably not a priority).
>
> 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 :)

> In short, use the forc-... errr, plumbing ;).
>
> --
> Cheers,
>
> Sverre Rabbelier
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Sverre Rabbelier
On Thu, Jul 31, 2008 at 23:44, cte <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Shawn Pearce
Sverre Rabbelier <[hidden email]> wrote:

> On Thu, Jul 31, 2008 at 23:44, cte <[hidden email]> 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.

And actually if you try to use topo-order internally in C you still
have to wait for the post-processing.  Which is going to cause your
UI to lock up because it is single-threaded as both Git and your UI
toolkit are probably single threaded.  At least by forking out to
git-rev-list your UI can respond while the computation is happening
in a background process.
 
> Especially since that'd mean that integrating it into other languages
> (by means of wrappers), such as Python or Ruby, becomes a lot easier.

I'm going to be shot for saying this, but both Python and Ruby
have implementations that run on the JVM.  So does Git.  Want
to use Git and Python?  Use JGit and Jython.  :)
 

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

Too many people have scripts based upon plumbing to make incompatible
changes.  We'd have all of our users screaming.  Remember many Git
users are programmers themselves, they will make small home-grown
scripts based upon Git plumbing to simplify their workflow and
everyday tasks.  They use plumbing precisely because they can trust
it won't change or break on them.

--
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Sverre Rabbelier
On Thu, Jul 31, 2008 at 23:58, Shawn O. Pearce <[hidden email]> wrote:
> And actually if you try to use topo-order internally in C you still
> have to wait for the post-processing.....

Aye, that's what I was reffering to, thanks for clarifying :).

>> Especially since that'd mean that integrating it into other languages
>> (by means of wrappers), such as Python or Ruby, becomes a lot easier.
>
> I'm going to be shot for saying this, but both Python and Ruby
> have implementations that run on the JVM.  So does Git.  Want
> to use Git and Python?  Use JGit and Jython.  :)

Heheh, nice plug :P, but thanks but no thanks. I'd rather have
something more native than "JGit + Jython", two levels of 'emulation'
can't be good!

> Too many people have scripts based upon plumbing to make incompatible
> changes.....

Exactly! :)

--
Cheers,

Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: linking libgit.a in C++ projects

Dmitry Potapov
In reply to this post by cte
On Fri, Aug 1, 2008 at 1:44 AM, cte <[hidden email]> 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.

There is no problem with parsing. If you want to receive the output
in the specific order, Git has to read everything first, and that
is *slow*. So, --topo-order is convenient but slow, and it is slow
not because it is piping data, but because it takes some time to
read the whole history.

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

"Flexible" is not a synonym of the word "useful". For instance, using
core functions will not help you to overcome the aforementioned problem.
Drawing a graph is NOT what git core functions about. You have to do
that in your GUI, and to do that when revisions are given to you in
arbitrary order is not easy. Yet, it is something what good GUI should
be capable to handle, because otherwise the response time will be bad.


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
12