Introduce RemoteCollection.Rename. #741

Therzok · 2014-06-02T19:17:53Z

Ready to merge on sight!

Therzok · 2014-06-02T19:18:01Z

Therzok · 2014-06-03T10:08:39Z

In fact, should I just use the internal delegate for interop and make the RemoteCollection.Rename take a Func<string, bool> ?

carlosmn · 2014-06-03T14:16:24Z

I like the idea of making it a Func<string, bool>, but @nulltoken knows better. I'm not sure about the compatibility stuff (or even if it's relevant here).

The way you bring in the user's callback is typically by always passing in our own, and passing the user's callback as the pyaload and performing the marshalling of the string in the callback. You can check out e.g. RemoteCallbacks.cs for this pattern.

dahlbyk · 2014-06-04T03:20:26Z

A callback for this doesn't seem particularly idiomatic. Maybe return a RemoteRenameResult (or just IEnumerable<string>?) with the problem refs?

Therzok · 2014-06-04T03:34:42Z

I could do that. So I just resolve the refspec and tell the user it failed?

Therzok · 2014-06-04T03:35:43Z

Also, this requires at least libgit2/libgit2@dfcba09

dahlbyk · 2014-06-04T03:58:44Z

I could do that. So I just resolve the refspec and tell the user it failed?

I don't think there's anything to resolve, just marshal the string parameter and add it to the problem spec list.

Therzok · 2014-06-05T11:49:00Z

I still have a nitpick, I don't know how to trigger the problematic refspecs issue. Any pointers on how to trigger it to have some unit tests around it?

Therzok · 2014-06-05T11:49:30Z

LibGit2Sharp/Core/Proxy.cs

+                    int res = NativeMethods.git_remote_rename(
+                        remote,
+                        new_name,
+                        (problem, payload) => { failingRemotes.Add(problem); return 0; },


Would this work? Or should I create a specific delegate on top of the delegate type?

I mean, I'm unsure if the custom marshaler applies here. I could create a delegate based on rename_problem_cb which wouldn't be collected in this scope.

This works for me. What does the return value mean?

0 to ignore error, 1 if you want an error message and stop.

See this.

dahlbyk · 2014-06-05T16:43:53Z

I still have a nitpick, I don't know how to trigger the problematic refspecs issue. Any pointers on how to trigger it to have some unit tests around it?

Try manually creating refs/remote/renamed/master and then rename origin to renamed. That should create a conflict in renaming origin/master to renamed/master.

Therzok · 2014-06-05T16:45:30Z

That's another test!

Therzok · 2014-06-05T16:49:11Z

And by that I mean, I already have more running. :D

Therzok · 2014-06-05T16:54:20Z

@dahlbyk Whoa, thanks for that test. It uncovered a bug in libgit2.

Therzok · 2014-06-05T17:03:58Z

LibGit2Sharp.Tests/RemoteFixture.cs

+
+                var failing = repo.Network.Remotes.Rename("origin", "renamed");
+                // This fails in libgit2. It changes the manually added ref to /remotes/renamedd/master.
+                //Assert.NotEmpty(failing);


This is most likely a bug in libgit2. The ref I added above is renamed to refs/remotes/renamedd/master.

There's a PR in libgit2. I however don't think failing should contain anything. That reference gets overwritten, as it doesn't belong to a repository.

Guess I'll remove that and this is ready to merge.

So @carlosmn in what case would we expect the "problem refspec" callback to fire on a rename?

@dahlbyk from what I understood, only when the default fetch refspec doesn't contain the remote name under /refs/remotes/<namehere>/.

nulltoken · 2014-06-06T11:31:23Z

LibGit2Sharp/RemoteCollection.cs

+        /// <param name="name">The current remote name.</param>
+        /// <param name="newName">The new name the existing remote should bear.</param>
+        /// <returns>An <see cref="IEnumerable{T}"/> containing the refspecs which failed to be renamed and need manual modifications.</returns>
+        public virtual IEnumerable<string> Rename(string name, string newName)


Actually, from an API perspective, I think this method should rather return a Remote. This would mimic what other collections do.

So the list of failed refspecs may rather end up being returned in a call back (maybe bearing a similar signature than UnmatchedPathHandler)

That was the first approach, but @dahlbyk told me this would be a better approach. Please decide. :D

The thing is, the user cant' do anything with that without triggering another interop command and that would blow up on mono. Better just collect them and tell the user to modify them himself.

Actually, it won't blow up, since we're in managed land when we get on the callback. But the user still can't do much with that data at that time.

I agree, this is why the callback isn't "stoppable" (it returns void). It would optionally notify the user of refspecs that haven't been properly dealt with.

So, should I change this?

That was the first approach, but @dahlbyk told me this would be a better approach. Please decide. 💃

This is my fault. I overlooked this and got a bit late in the game. Let's make this return a Remote and if/when I'll have the chance to meet both of you in person, I'll treat you with 🍻.

Deal? 😉

nulltoken · 2014-06-06T11:39:37Z

@Therzok Pretty neat!

Therzok · 2014-06-06T12:34:14Z

/cc @nulltoken how's it now?

Therzok · 2014-06-06T12:47:18Z

LibGit2Sharp/Core/Proxy.cs

+                    int res = NativeMethods.git_remote_rename(
+                        remote,
+                        new_name,
+                        (problem, payload) => { callback(problem); return 0; },


I could send the callback as payload, but this works too and it's shorter and more concise.

Couldn't we rather pass IntPtr.Zero (rather than an empty callback) when the user doesn't want to be notified?

Grmpf... The callback doesn't seem to be as optional as it should be (cf https://github.com/libgit2/libgit2/blob/development/src/remote.c#L1450)

/cc @carlosmn

I think we should go with returning a list of strings instead of using a callback, but making it optional would be a good first step.

How would you handle normal rename issues then?

What would these "normal" issues be? AFAICT we only call this for non-default refspecs.

Oh, I see, you meant a ref param with a list of strings.

Yeah, what in C# would be an out param where we tell the caller what went wrong, since this has nothing to do with events and thus doesn't need a callback.

Actually, I'd rather avoid relying on ref/out params on public API as none of the user facing methods behave this way.

Right, I'm talking about the C interface. Hence the "would" :p You still get to keep your fancy return values.

carlosmn · 2014-06-06T14:39:28Z

I've gone ahead and removed the callback in libgit2/libgit2#2407 and replaced it with a git_strarray.

Therzok · 2014-06-06T14:40:00Z

Shall I bump native binaries?

carlosmn · 2014-06-06T14:41:11Z

Hold off until it's actually merged.

nulltoken · 2014-06-06T14:41:20Z

LibGit2Sharp/Handlers.cs

@@ -79,6 +79,15 @@
    public delegate void UnmatchedPathHandler(string unmatchedPath);

    /// <summary>
+    /// Delegate definition for rename failure callback.
+    /// <para>
+    ///   This callback will be called to notify the caller of remotes which need manual modifications.


Shamelessly inspired from libgit2 remote.h

This callback will be called to notify the caller of fetch refspecs that haven't been automatically updated and need potential manual tweaking.

Therzok · 2014-06-06T15:30:41Z

@nulltoken All of the current issues fixed. Shall we wait for the libgit2 PR and bump and update or merge as is?

nulltoken · 2014-06-06T18:07:23Z

All of the current issues fixed

@Therzok Awesome work! 👍 ‼️

Shall we wait for the libgit2 PR and bump and update or merge as is?

Don't worry, we'll update the binaries later. I'm pretty sure @carlosmn is hard at work trying to find so many interesting ways the break the libgit2 API. Again. 😉

Therzok · 2014-06-06T18:39:24Z

Coool. :D I can now get to working on stuff on XS side. I'll be back with contributions after the weekend.

nulltoken · 2014-06-06T18:46:03Z

🚀

carlosmn mentioned this pull request Jun 3, 2014

Concurrent ref iterator access libgit2/libgit2#2395

Merged

Therzok changed the title ~~Unfinished remote rename implementation.~~ Introduce RemoteCollection.Rename. Jun 5, 2014

Therzok reviewed Jun 5, 2014
View reviewed changes

carlosmn mentioned this pull request Jun 5, 2014

Remote rename fixes libgit2/libgit2#2404

Merged

nulltoken reviewed Jun 6, 2014
View reviewed changes

Therzok reviewed Jun 6, 2014
View reviewed changes

carlosmn mentioned this pull request Jun 6, 2014

More remote rename fixes libgit2/libgit2#2407

Merged

nulltoken reviewed Jun 6, 2014
View reviewed changes

Introduce RemoteCollection.Rename.

e1b6166

nulltoken merged commit e1b6166 into libgit2:vNext Jun 6, 2014

nulltoken added this to the v0.19.0 milestone Jun 6, 2014

Therzok deleted the remoteRename branch June 7, 2014 00:50

nulltoken mentioned this pull request Aug 24, 2014

Introduce RemoteCollection.Rename #730

Closed

Introduce RemoteCollection.Rename. #741

Introduce RemoteCollection.Rename. #741

Uh oh!

Conversation

Therzok commented Jun 2, 2014

Uh oh!

Therzok commented Jun 2, 2014

Uh oh!

Therzok commented Jun 3, 2014

Uh oh!

carlosmn commented Jun 3, 2014

Uh oh!

dahlbyk commented Jun 4, 2014

Uh oh!

Therzok commented Jun 4, 2014

Uh oh!

Therzok commented Jun 4, 2014

Uh oh!

dahlbyk commented Jun 4, 2014

Uh oh!

Therzok commented Jun 5, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dahlbyk commented Jun 5, 2014

Uh oh!

Therzok commented Jun 5, 2014

Uh oh!

Therzok commented Jun 5, 2014

Uh oh!

Therzok commented Jun 5, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nulltoken commented Jun 6, 2014

Uh oh!

Therzok commented Jun 6, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!