librelist archives

« back to archive

[libgit2][libgit2sharp] Thinking about starting to work on refs handling

[libgit2][libgit2sharp] Thinking about starting to work on refs handling

From:
Emeric Fermas
Date:
2010-12-24 @ 13:14
Hello,

Currently, a Repository is able to Resolve (lookup) an object by
providing a sha1 identifier.

using (var repo = new Repository("path/to/repo")
{
      // Preferred method of resolving git objects by specifying the
expected type
      Tag tag = repo.Resolve<Tag>("0c37a5391bbff43c37f0d0371823a5509eed5b1d");

      // Second method of resolving of git objects (less performant)
      GitObject gitObject =
repo.Resolve("0c37a5391bbff43c37f0d0371823a5509eed5b1d"); // Type of
object is not specified, the Resolver does the guessing heavy lifting
by firstly invoking git_odb_read_header()
      Assert(gitObject is Tag):
}


I'm playing with the idea of starting to work in the 'refs' area and,
I'd like to implement something like that:

using (var repo = new Repository("path/to/repo")
{
      Branch head = repo.Head; // similar to 'git symbolic-ref <name>'
      Commit commit = head.Tip;
      string name = head.name; // eg. refs/heads/master, refs/heads/story82
}


I'd also like to to add overloads to the Resolve method which would
take a ref name:

using (var repo = new Repository("path/to/repo")
{
      Tag tag = repo.Resolve<Tag>("refs/tags/v1.0");

      // Would work as well without specifying the type
      GitObject gitObject = repo.Resolve("refs/tags/v1.0");
      Assert(gitObject is Tag):
}

A Repository would expose as well the Tags and Branches as read-only properties.


In order to achieve this, maybe the git-repository should hold some
kind of database of "references" which would be freed when
git_repository_free() is called. This database would be lazily
populated and updated (in a similar way to git_repository_lookup() and
repository.write_back()).


However, before starting any kind of spike code in libgit2, I'd really
like your feedback about the .Net API binding proposal and
recommendations/advices about what the libgit2 interface should look
like.


Cheers,
Em.