exporting git commands in parsable format for constructing language-specific API for git CLI

exporting git commands in parsable format for constructing language-specific API for git CLI

[ama bamo]

While using git commands in my applications and reimplementing the
same stuff i found out i can just parse git docs then generate
structures and classes based on that; i have done similiar for
wordpress and its `wp-cli`, for example see:
https://github.com/bukowa/gowpcli/tree/master/generated

But `wp-cli` allows exporting all of the commands in a json format,
see: https://github.com/bukowa/gowpcli/blob/master/generate/dump.json

Is there anyone who thinks that would be benefical to do something
similiar for git, or maybe there's something done already and i missed
that? (parsing manpages / generated htmldocs is still a pain).

Thank you,
Mateusz Kurowski

Re: exporting git commands in parsable format for constructing language-specific API for git CLI

[Santiago Torres Arias]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Sat, Mar 27, 2021 at 01:42:09AM +0100, ama bamo wrote:
> While using git commands in my applications and reimplementing the
> same stuff i found out i can just parse git docs then generate
> structures and classes based on that; i have done similiar for
> wordpress and its `wp-cli`, for example see:
> https://github.com/bukowa/gowpcli/tree/master/generated
> 
> But `wp-cli` allows exporting all of the commands in a json format,
> see: https://github.com/bukowa/gowpcli/blob/master/generate/dump.json

I'm not entirely sure if something like this exists in git, and I'm
alsot unsure of what exactly is the benefit of doing so vs an actual API
(e.g., git2go[1]). Could you help us by elaborating what this is meant to
achieve? Maybe that way we can figure out if something exists...

Cheers!
-Santiago

[1] https://github.com/libgit2/git2go

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: exporting git commands in parsable format for constructing language-specific API for git CLI

[ama bamo]

Hey Santiago!

Sorry for not being more specific - it's my first time in such a mailing list.

libgit2 and it's language-specific API looks interesting but
its not the solution to the problem i am trying to solve.

I believe that git CLI is the most stable,reliable and tested way
of actually using git. Most of the tools using git that i know
are actually using your underlying git cli binary - not the bindings.

By following the definition of CLI and API; the CLI is human readable
while the API is machine readable. If we were able to expose CLI
in a machine-readable format then would it be an API?


On Mon, Mar 29, 2021 at 1:07 AM Santiago Torres Arias <santiago@nyu.edu> wrote:
>
> On Sat, Mar 27, 2021 at 01:42:09AM +0100, ama bamo wrote:
> > While using git commands in my applications and reimplementing the
> > same stuff i found out i can just parse git docs then generate
> > structures and classes based on that; i have done similiar for
> > wordpress and its `wp-cli`, for example see:
> > https://github.com/bukowa/gowpcli/tree/master/generated
> >
> > But `wp-cli` allows exporting all of the commands in a json format,
> > see: https://github.com/bukowa/gowpcli/blob/master/generate/dump.json
>
> I'm not entirely sure if something like this exists in git, and I'm
> alsot unsure of what exactly is the benefit of doing so vs an actual API
> (e.g., git2go[1]). Could you help us by elaborating what this is meant to
> achieve? Maybe that way we can figure out if something exists...
>
> Cheers!
> -Santiago
>
> [1] https://github.com/libgit2/git2go

Re: exporting git commands in parsable format for constructing language-specific API for git CLI

[Junio C Hamano]

ama bamo <pythoncontrol@gmail.com> writes:

> By following the definition of CLI and API; the CLI is human readable
> while the API is machine readable. If we were able to expose CLI
> in a machine-readable format then would it be an API?

Both input and output for Porcelain commands are subject to change
to improve the end user experience for humans, which may break
scripts that hardcodes the assumption of either the input or the
output at one version of Git.

So no, I wouldn't call that an API.