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
|

Re: linking libgit.a in C++ projects

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

Didn't mean to imply that somehow it is no longer a post-processing op if you
aren't using git plumbing. The discussion shows, however, that if gitk
was actually
doing the revision traversals, then it would be able to trigger events
that update the
gui whenever it wanted, which would have allowed it to implement the
early output
feature without changing any of the git source. Instead, git-log had
to be altered to
address gitk's needs, and an option was added that users don't
typically use. This is
not exactly what I would consider spartan programming
(http://www.codinghorror.com/blog/archives/001148.html),
plus there are already too many options to remember! Anyways, I
suppose it is pointless
to argue about which approach is better, because both have trade-offs,
and the correct
path depends on your use case.

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

Definitely not questioning his ability to maintain backwards
compatibility; it was
merely an observation about your strange definition of correct. In school, when
I completed 95% of a proof, it was never marked as "correct", and I
was told that I hadn't actually proven anything. Those damn teachers :)
--
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

Linus Torvalds-3


On Thu, 31 Jul 2008, cte wrote:
>
> Instead, git-log had to be altered to address gitk's needs, and an
> option was added that users don't typically use.

Actually, no.

I ended up doing a hack to add "git log --early-output", and some quick
hacks to make git use it. But I'm happy to say that gitk doesn't use it
any more. Gitk just parses the normal git log output, although obviously
it ends up needing enough data to be able to fill in the gaps (ie it uses
the "--parents" flag to get the rewritten parenthood info and the merges
to keep it together).

So yeah, we have some options that enable output that simply doesn't make
_sense_ to humans, but does when you are post-processing it (git has
always had those, since it very much was about scripting from day one),
but no, at least gitk doesn't use any really odd ones.

It literally does

        git log --no-color -z --pretty=raw --parents --boundary

(plus the args the user gave it). The --no-color turns off color if it's
enabled by default.

The -z makes it the git log output a bit easier to parse by using a NUL
character between commits.

The --pretty=raw is just to give the full/raw commit info - like giving
the timestamps in the native raw format that is much easier to parse than
any human-readable format.

The --parents I already mentioned - it is what makes you able to stitch
the commits together (and it's useful for other things too: any scripts
that look for merges will tend to use it, for example)

And the --boundary is to show the commits that aren't part of the actual
selected set in gray.

It's all pretty generic, in other words. The -z option is purely for
machine parsing, the others _can_ actually be useful even for humans (eg,
--boundary together with --left-right and --pretty=oneline actually is
very readable if you are used to that format).

So it's very true that git in general is geared towards scripting (and
we've often added things to make it even more so), but no, your particular
complaint isn't true. gitk doesn't do anything really strange.

                Linus
--
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
> So it's very true that git in general is geared towards scripting (and
> we've often added things to make it even more so), but no, your particular
> complaint isn't true. gitk doesn't do anything really strange.

Yeah, I guess that's why I like using git so much; a few piped
commands and a script or two, and you can do some pretty rad stuff.
--
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 Avery Pennarun
Avery Pennarun, Thu, Jul 31, 2008 20:55:26 +0200:

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

Didn't mean them. Meant the globally visible names. libgit does not
use a prefix for its exported symbols. They will clash with the
symbols of the programs it is linked to.

--
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
Alex Riesen wrote:

> Avery Pennarun, Thu, Jul 31, 2008 20:55:26 +0200:
>> 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.
>>
>
> Didn't mean them. Meant the globally visible names. libgit does not
> use a prefix for its exported symbols. They will clash with the
> symbols of the programs it is linked to.
>

But that's a problem for C programs, C++ programs will not have that
problem, right? ;-)

With C programs these git symbols can be avoided.

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

Steve Frécinaux
In reply to this post by Shawn Pearce
On Thu, Jul 31, 2008 at 11:58 PM, Shawn O. Pearce <[hidden email]> wrote:
>> 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 also the "stores" branch from pygit [1] that implements pack
and object reading natively in python. Anyway implementing more than
that (ie, packing and such things) natively is clearly harder and
takes more work for less efficiency than making bindings around a
libified git...

[1] http://code.istique.net/?p=pygit.git;a=shortlog;h=refs/heads/stores
Don't mind the 50X error, just refresh... broken server.
--
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