Proper pull, fetch, merge support

[synhershko]

Currently there doesn't seem to be a way to do a pull, or even a separate fetch-merge operation. Will be nice, and quite useful, to have this...

[nulltoken]

Hello Itamar,

Will be nice, and quite useful, to have this...

I fully agree with you :) @carlosmn is working hard to make this happen. Once the feature is available and tested in libgit2, we'll make sure that LibGit2Sharp benefit from it quickly.

BTW, from an API standpoint, how would you like to use it? What would be the client code you'd like to write?

[synhershko]

Looking forward to it...

I guess new Repository(path).Pull(origin) and new
Repository(path).Fetch(origin) ?

Either this or through the Remotes API. I'm not familiar with your API
enough, but I think pulling made on a repository given a remote name makes
the most sense.

On Mon, Sep 19, 2011 at 11:49 AM, nulltoken <
reply@reply.github.com>wrote:

Hello Itamar,

Will be nice, and quite useful, to have this...

I fully agree with you :) @carlosmn is working hard to make this happen.
Once the feature is available and tested in libgit2, we'll make sure that
LibGit2Sharp benefit from it quickly.

BTW, from an API standpoint, how would you like to use it? What would be
the client code you'd like to write?

Reply to this email directly or view it on GitHub:
#65 (comment)

[nulltoken]

Looking forward to it...

I'm going to keep this issue open as a reminder. It will be updated as soon as something testable pops up.

[carlosmn]

The library already supports fetching (not every efficiently, but that'll come in good time). Personally I don't like new Repository(path).Fetch(origin), because that can block (for a few minutes if you're unlucky). What the library has now (in C) is more like

Remote origin = new Remote(path).Remote("origin");
origin.Connect();
origin.Negotiate();
if (origin.NeedsPack) {
  origin.DownloadPack();
}

All of the network operations should be run in a worker thread and you probably don't want to create another repository object since you probably already have one somewhere.

[synhershko]

Don't mind the new stuff, I was sketching code...

My problem with this syntax is it doesn't mimic the normal git operation.
The .NET wrapper is enough high level to allow that, IMHO.

Also, what about merges? in my scenario I'm not expecting conflicts, hence
I'm interested in using Pull.

On Mon, Sep 19, 2011 at 5:43 PM, Carlos Martn Nieto <
reply@reply.github.com>wrote:

The library already supports fetching (not every efficiently, but that'll
come in good time). Personally I don't like new Repository(path).Fetch(origin), because that can block (for a few minutes
if you're unlucky). What the library has now (in C) is more like

Remote origin = new Remote(path).Remote("origin");
origin.Connect();
origin.Negotiate();
if (origin.NeedsPack) {
 origin.DownloadPack();
}

All of the network operations should be run in a worker thread and you
probably don't want to create another repository object since you probably
already have one somewhere.

Reply to this email directly or view it on GitHub:
#65 (comment)

[carlosmn]

It replicates how the git protocol works. The git command-line tool obviously does it all at once. The C# layer can certainly simplify the method all it wants to, and we may eventually take (some of) it into the library.

Merges need merge-base calculation support and the whole diff machinery, which will take a bit of time (help writing and reviewing code is always appreciated). I don't think there should be an explicit pull operation, but rather fetch + merge, both of these steps being explicitly run.

[synhershko]

I'm too against doing just pull, but in some scenarios (like mine: auto deployment) that is more than acceptable to make. It should be easy to with with an extension function, so I don't really mind.

What is lacking in the merge and diff arena? there's plenty of OSS code that should get you jumpstarted on that one, no?

I'm too swamped with work and projects as it is, but I'd like to understand what needs to be done.

Feel free to e-mail me directly to prevent this thread from bloating.

[synhershko]

I'm too against doing just pull, but in some scenarios (like mine: auto
deployment) that is more than acceptable to make. It should be easy to with
with an extension function, so I don't really mind.

What is lacking in the merge and diff arena? there's plenty of OSS code that
should get you jumpstarted on that one, no?

I'm too swamped with work and projects as it is, but I'd like to understand
what needs to be done.

Feel free to e-mail me directly to prevent this thread from bloating.

On Mon, Sep 19, 2011 at 6:23 PM, Carlos Martn Nieto <
reply@reply.github.com>wrote:

It replicates how the git protocol works. The git command-line tool
obviously does it all at once. The C# layer can certainly simplify the
method all it wants to, and we may eventually take (some of) it into the
library.

Merges need merge-base calculation support and the whole diff machinery,
which will take a bit of time (help writing and reviewing code is always
appreciated). I don't think there should be an explicit pull operation, but
rather fetch + merge, both of these steps being explicitly run.

Reply to this email directly or view it on GitHub:
#65 (comment)

[synhershko]

Hey, any word on what needs to be done?

[nulltoken]

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.

[synhershko]

Yay, thanks. I will have a look as soon as I can.

[nulltoken]

Relevant information in libgit2 issue #501.

[uluhonolulu]

So I thought I'd give it a try, and the last line of this code gives me an AccessViolationException:

var path = @"F:\Projects\Fubu\Chpokk";
var result = NativeMethods.git_repository_open(out repository, PosixPathHelper.ToPosix(path));
Assert.NotNull(repository);
Assert.AreEqual(0, result);
result = NativeMethods.git_remote_new(out remote, repository, "git@github.com:uluhonolulu/Chpokk.git", null);
Assert.AreEqual(0, result);
result = NativeMethods.git_remote_connect(remote, NativeMethods.GIT_DIR_FETCH);

My native method declarations are:

    public const int GIT_DIR_FETCH = 0;

    [DllImport(libgit2)]
    public static extern int git_remote_new(
        out RemoteSafeHandle remote,
        RepositorySafeHandle repo,
        [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof(Utf8Marshaler))] string url,
        [MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof(Utf8Marshaler))] string name);

    [DllImport(libgit2)]
    public static extern int git_remote_connect(
        RemoteSafeHandle remote, 
        int direction);

I should admit I was too lazy to build and run the C code.

[nulltoken]

@uluhonolulu AccessViolationException confirmed. I'm going to troubleshoot this.

Meanwhile, using git://github.com/libgit2/libgit2.git or http://github.com/libgit2/libgit2.git seems to be ok.