[erlang-questions] erlgit - convenience Erlang wrapper around git executable

[Gleb Peregud]

Hello again folks!

I am glad to present yet another project open sourced by LivePress
Inc. This time it is a standalone convenience wrapper around git
executable:

https://github.com/gleber/erlgit

Here's an example of usage, which says everything about the project itself:

1> Local = "/tmp/erlgit".
"/tmp/erlgit"
2> git:clone("http://github.com/gleber/erlgit.git", Local).
{ok,"Cloning into '/tmp/erlgit'...\n"}
3> git:branches(Local).
["master"]
4> git:refs(Local).
[{"HEAD",'HEAD',"097428dda56dec6085747387645d6020f86cfae7"},
{"master",head,"097428dda56dec6085747387645d6020f86cfae7"},
{"origin/HEAD",remote, "097428dda56dec6085747387645d6020f86cfae7"},
{"origin/master",remote, "097428dda56dec6085747387645d6020f86cfae7"},
{"v0.3.0",tag,"be3b0ade881666286801ee8b218ecbf29da97558"},
{"v0.3.1",tag,"89f2d81be12f6034db52fd6d71d8a4b96f4ee9de"},
{"v0.3.2",tag,"3dc42981d9e4677654370614888ec3f368421240"},
{"v0.5.0",tag,"097428dda56dec6085747387645d6020f86cfae7"}]
5> git:branch(Local).
"master"
6> git:tags(Local).
["v0.3.0","v0.3.1","v0.3.2","v0.5.0"]
7> os:cmd("touch "++Local++"/new_file").
[]
8> git:status_is_dirty(Local).
true
9> git:status_changed_files(Local).
[{untracked,"./new_file"}]
10> os:cmd("echo >> "++Local++"/README.md").
[]
11> git:status_changed_files(Local).
[{modified,"./README.md"},{untracked,"./new_file"}]
12> git:add_files(Local, ["new_file"]).
{ok,[]}
13> git:status_changed_files(Local).
[{modified,"./README.md"},{indexed_added,"./new_file"}]
14> git:commit(Local, "update README and add file").
{ok,"[master 3825b3c] update README and add file\n 0 files changed\n
create mode 100644 new_file\n"}
15> git:head(Local).
"3825b3cb5e713c5145b4b74445a4d5e6187e567d"

and it has some support for semantic versioning using erlsemver library:

16> rr("deps/erlsemver/include/*").
[semver]
17> git:version_tags(Local).
[#semver{x = 0,y = 3,z = 0,pre = <<>>,build = undefined},
#semver{x = 0,y = 3,z = 1,pre = <<>>,build = undefined},
#semver{x = 0,y = 3,z = 2,pre = <<>>,build = undefined},
#semver{x = 0,y = 5,z = 0,pre = <<>>,build = undefined}]
18> git:tag(Local, semver:inc_z(#semver{x = 0,y = 5,z = 0,pre =
<<>>,build = undefined})).
#semver{x = 0,y = 5,z = 1,pre = <<>>,build = undefined}
19> lists:last(git:version_tags_commits(Local)).
{#semver{x = 0,y = 5,z = 1,pre = <<>>,build = undefined},
"3825b3cb5e713c5145b4b74445a4d5e6187e567d"}

I hope it will be useful for someone except for me.

Cheers,
Gleb Peregud
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Motiejus Jakštys]

On Fri, Aug 24, 2012 at 10:44:47PM +0200, Gleb Peregud wrote:
> Hello again folks!
>
> I am glad to present yet another project open sourced by LivePress
> Inc. This time it is a standalone convenience wrapper around git
> executable:
>
> https://github.com/gleber/erlgit
>
>

> I hope it will be useful for someone except for me.

Funny coincidence. Today I was thinking about making libgit2[1] bindings
for Erlang (I need some time-consuming project for my final year
university project, ideas welcome). Would that be useful? Probably
not.. And here you go :)

If somebody will convince me that libgit2 bindings to Erlang is a
valid/necessary use case.. I will do that. Anyone?

Motiejus

[1]: http://libgit2.github.com/

[Gleb Peregud]

Actually there is one which is in it's infancy:
https://github.com/schacon/geef - it needs a lot of love to be useful
for any high-level git repository manipulations. erlgit uses git
executable, which is always a bad solution in a long run, so in a long
run I had a vision where geef implements low level libgit2 features
and erlgit uses geef to provide a easy to use high level API.

[Max Lapshin]

I've just looked for something like this yesterday =)

I consider, that grit https://github.com/mojombo/grit approach is
best: for frequently used operations, like "read head",
you should unpack git repo by yourself: read pack files, decode them
and parse their content.

Usage of libgit2 is nice, but it is nif. It should be used for speed.

[Gleb Peregud]

On Sat, Aug 25, 2012 at 8:14 AM, Max Lapshin <max.l...@gmail.com> wrote:
> I've just looked for something like this yesterday =)
>
> I consider, that grit https://github.com/mojombo/grit approach is
> best: for frequently used operations, like "read head",
> you should unpack git repo by yourself: read pack files, decode them
> and parse their content.
>
> Usage of libgit2 is nice, but it is nif. It should be used for speed.

I guess all approaches are feasible depending on the needs. Currently
just a wrapper around git executable is good enough for my needs, but
in theory it is the worst approach, since it depends on output of user
facing executable. I am glad to accept patches which uses any method.
I like libgit2 approach better than manually parsing git repo, since
it is much less work - and yet it works for anyone who isn't concerned
about concurrency aspect.