Interfacing Git

[dmitry-kazakov]

Is there such a thing in Ada?

What I have found so far is the ligbit2 library and Ada bindings project to a-libgit2
which looks pretty much dead.

libgit2 seems sort of overblown. To compare, the Perforce client library (p4api) has only a few functions.

Is libgit2 worth bindings?

Would a direct communication from Ada be better?

[Irvise]

What would be the goal of the interfacing between Ada and Git? An Ada-written git client perhaps? A more git aware Ada thingy?

[dmitry-kazakov]

Well, there could be useful applications:

• A virtual file system to show releases in a consistent way using conventional tools rather than command line tinkering and web pages. You could even edit/compile/test/commit directly into Git.
• A caching subsystem. E.g. there is so-called Git Virtual File system from Microsoft that does that.
• A project management system (rather than messy file management).

[ Not that I committed to do anything like that ]

[Irvise]

@dmitry-kazakov

A project management system (rather than messy file management).

Check Fossil Fossil: A Coherent Software Configuration Management System It is created by the same people behind SQLite and Tcl/Tk

For the rest… I have not much more to add…

[dmitry-kazakov]

@Irvise

Check Fossil Fossil: A Coherent Software Configuration Management System

Thanks for the link, but that does not look like project management where you can walk releases of a project and get a consistent view of releases of all other projects linked to this one.

@Irvise

It is created by the same people behind SQLite and Tcl/Tk

Negative advertising?

[nerd_type]

I’m curious how you would use git for a project management system.

Do you requirements for such a system?

[dmitry-kazakov]

I would use it as a backend. Like any other file controlling system (Perforce, MKT, Subversion) Git is just a database you can drop into and take from versioned files.

It should be fast, allow storing artefacts (object and executables), support locking (e.g. to prevent or at least keep under control merging/branching madness). The rest can be implemented on top: views, releases, release related source adjustments (like placing version info into files), automatic tests. automatic release install/packaging, automatic release update builds etc.