git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: linking libgit.a in C++ projects

From
SRSverre Rabbelier <alturin@gmail.com>
Date
Jul 31, 2008, 21:51 UTC
Message-ID
<bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com>
In-Reply-To
<ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.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?

Show 6 quoted lines
> 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.

Show 6 quoted lines
>> 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".

Show 7 quoted lines
>> 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
Previous: cteNext: Shawn O. Pearce
Message 9 of 26 in “linking libgit.a in C++ projects”
  1. cteJul 31, 2008
  2. Dmitry PotapovJul 31, 2008
  3. cteJul 31, 2008
  4. Pedro MeloJul 31, 2008
  5. Petr BaudisJul 31, 2008
  6. cteJul 31, 2008
  7. Sverre RabbelierJul 31, 2008
  8. cteJul 31, 2008
  9. Sverre RabbelierJul 31, 2008
  10. Shawn O. PearceJul 31, 2008
  11. Sverre RabbelierJul 31, 2008
  12. Steve FrécinauxAug 4, 2008
  13. cteAug 1, 2008
  14. Linus TorvaldsAug 1, 2008
  15. cteAug 1, 2008
  16. Dmitry PotapovJul 31, 2008
  17. Petr BaudisJul 31, 2008
  18. cteJul 31, 2008
  19. Dmitry PotapovJul 31, 2008
  20. Boaz HarroshJul 31, 2008
  21. Dmitry PotapovJul 31, 2008
  22. Alex RiesenJul 31, 2008
  23. Avery PennarunJul 31, 2008
  24. Alex RiesenAug 3, 2008
  25. Boaz HarroshAug 4, 2008
  26. cteJul 31, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.