-
Notifications
You must be signed in to change notification settings - Fork 2.5k
More remote rename fixes #2407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More remote rename fixes #2407
Conversation
We don't allow renames of anonymous remotes, so there's no need to handle them. A remote is always associated with a repository, so there's no need to check for that.
We must make sure that the name pointer remains valid, so make sure to allocate the new one before freeing the old one and swap them so the user never sees an invalid pointer.
Hold off on this for a bit, I forgot that we also fail to retarget symrefs. |
Really like this callback removal. I really don't wanna put pressure on you, but I promised @arrbee I'd tag a release candidate this weekend, so if you could wrap this up, it'd be niiiiice. :p |
There is no reason why we need to use a callback here. A string array fits better with the usage, as this is not an event and we don't need anything from the user.
A symref inside the namespace gets renamed, we should make it point to the target's new name. This is for the origin/HEAD -> origin/master type of situations.
This should be it as far as rename stuff goes. I'd also like to fix the remote-freeing we do on remove. Would you prefer a different pr for that or should I just push it here? |
This was a bad idea. Don't free except in the free function.
PUSH. IT. HERE. 😉 |
Yeah, I just went ahead and did that. |
Move fast and break |
We've never made a release with remote deletion, so this is one place where I didn't break it ;) |
More remote rename fixes
Remove a bunch of code and conditionals we just don't need and return the problems to the user as a list of strings instead of using a callback, which has no business being there.
From the discussion in libgit2/libgit2sharp#741