Hey, any word on what needs to be done?

Hello Itamar, sorry I've let this thread go cold.

First of all, the update of the working directory from a commit (checkout) doesn't work yet. So the Clone/Fetch experience will not be as rich as one could expect :)

Even if the API might change later (for instance, returning a [Fetch|Clone]Result or accepting callback parameters), for now, I'd go with the following pattern of usage.

using (var repo = new Repository(path))
{
   repo.Fetch(remoteAlias);
}

or

string fullPathToTheRepo = Repository.Clone(repoPath, remoteUrl);

I'd throw in some local and http Clone tests from a tiny repo within a SelfCleaningDirectory, asserting commits, refs, .... (To this purpose, I've forked @henon's TestGitRepository at https://github.com/nulltoken/TestGitRepository)

Then I'd dive in fetch.c example and bang my head in despair against the keyboard until the tests pass.

If this doesn't work, a more standard approach may help :)

Make sure fetch.c actually works (this will of course require to build libgit2 (see this and that)
Bind the extern'd methods in NativeMethods (depends.exe usually comes handy to troubleshoot potential issues)
Port the C code in C#
Make the tests pass
Refactor
Add some more tests
...

Please note, however, that this kind of task might put under the light some bugs (features-to-be?) in libgit2. When/If you encounter an issue, provided you're damn sure of your C# code, you'll eventually have to go back to C and port your non-working test from C# to C in order to give the libgit2 team something to chew while troubleshooting/fixing...

Concerning the diff, we might wait for this issue to be closed or temporarily rely on diffplex (or whatever) once the clone/fetch works.

Hope this helps,

Em.

Proper pull, fetch, merge support #65

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions