Skip to content

remote: add callback to resolve URLs before connecting#5056

Closed
eaigner wants to merge 13 commits intolibgit2:masterfrom
eaigner:remote-urlresolve-callback
Closed

remote: add callback to resolve URLs before connecting#5056
eaigner wants to merge 13 commits intolibgit2:masterfrom
eaigner:remote-urlresolve-callback

Conversation

@eaigner
Copy link
Copy Markdown

@eaigner eaigner commented Apr 21, 2019

I tried to move the original PR to another branch on my fork, and Github auto-closed my PR.
This is a new one replacing #5028.
Sorry for the dupe.


Since libssh2 doesn't read host configuration from the config file,
this callback can be used to hand over URL resolving to the client
without touching the SSH implementation itself.

Example:

Remote origin has URL

ssh://myhost/~/repo.git

This would obviously fail with the current libgit2 implementation,
given the following SSH config:

Host myhost
    User gituser
    HostName my.very.long.host.with.subdomain
    Port 1234

The URL callback allows this to be rewritten to e.g.

gituser@my.very.long.host.with.subdomain:1234/~/repo.git

by the client without much hassle.

Since libssh2 doesn't read host configuration from the config file,
this callback can be used to hand over URL resolving to the client
without touching the SSH implementation itself.
Comment thread include/git2/remote.h Outdated
Comment thread include/git2/remote.h Outdated
Comment thread src/remote.c
Comment thread src/remote.c Outdated
Comment thread src/remote.c Outdated
Comment thread src/remote.c Outdated
Comment thread src/remote.c Outdated
Comment thread src/remote.c Outdated
Comment thread src/remote.c Outdated
Comment thread tests/network/remote/remotes.c
Copy link
Copy Markdown
Member

@pks-t pks-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your amendments! One more thing, otherwise I'm good

Comment thread tests/network/remote/remotes.c Outdated
Comment thread src/remote.c Outdated
@eaigner
Copy link
Copy Markdown
Author

eaigner commented Apr 26, 2019

somehow the build system does not automatically build at the moment

@pks-t
Copy link
Copy Markdown
Member

pks-t commented Apr 26, 2019

/rebuild

@libgit2-azure-pipelines
Copy link
Copy Markdown

Okay, @pks-t, I started to rebuild this pull request as build #1839.

@pks-t
Copy link
Copy Markdown
Member

pks-t commented Apr 26, 2019

Thanks for alerting, I didn't notice

@pks-t
Copy link
Copy Markdown
Member

pks-t commented Apr 26, 2019

It looks like CI is building, but there's no status checks in our PRs anymore. @ethomson, got any clue why that is?

@ethomson
Copy link
Copy Markdown
Member

It looks like CI is building, but there's no status checks in our PRs anymore. @ethomson, got any clue why that is?

Let me find out.

@pks-t
Copy link
Copy Markdown
Member

pks-t commented Apr 29, 2019

/rebuild

@libgit2-azure-pipelines
Copy link
Copy Markdown

Okay, @pks-t, I started to rebuild this pull request as build #1847.

@pks-t
Copy link
Copy Markdown
Member

pks-t commented Apr 29, 2019

Trying another rebuild, as I saw other PRs do have checks again.

@ethomson
Copy link
Copy Markdown
Member

I don't 100% understand the checks architecture between GitHub and Azure Pipelines, but I think that there's only one-shot to get this hooked up. I think that GitHub notifies Azure Pipelines at PR creation and Azure Pipelines then sets itself up as a check. I think that one of those two deliveries failed, and so now this PR will forever not have checks from Azure Pipelines. Unfortunately that means we'll have to click through to the build manually.

I'll raise an issue to see if we can investigate.

@eaigner
Copy link
Copy Markdown
Author

eaigner commented Apr 29, 2019

Well https://dev.azure.com/libgit2/libgit2/_build/results?buildId=1847 says all checks have passed. Shouldn't that suffice?

@ethomson
Copy link
Copy Markdown
Member

Shouldn't that suffice?

Absolutely.

@tiennou what are you thinking here?

@tiennou
Copy link
Copy Markdown
Contributor

tiennou commented Apr 29, 2019

Weeell, on one hand I have some concern about adding a "backend" (this word ^^)-specific function that's more or less a workaround, eg. if I were to add libssh to the party*, I'd had to handle this customization point on top of its .ssh/config support (does we do ours before, after ?). Hence my technical answer would be to NAK, invoking layering violations, and the need for upstreaming.

On the other hand, I understand where this is coming from, the libssh2 project has limited bandwidth at the moment, and it really is a big chunk of actual missing functionality. Because of all this I'm reluctant to shot it down…

* which I'm debating doing, just so I can finally stop worrying about baking libssh2-specific things in our 1.0 interface 😉.

@ethomson
Copy link
Copy Markdown
Member

Indeed the impetus for this functionality came from the libssh2 limitation, however this does feel generally useful. It's basically programmatic insteadOf without having to deal with the configuration.

Copy link
Copy Markdown
Contributor

@tiennou tiennou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, okay, I think if we make it explicitly clear that this might not be the actual, final URL passed to the transport, I'm satisfied from a technical standpoint (ie. a libssh backend is by design allowed to re-substitute its own URL). This is the complexity I'm concerned about: this feels like a can of worm to me, like substituting the URL once, causing the lower layer to not recognize it anymore… Maybe I'm just too paranoid though 🤣.

I've reviewed this more closely, I think there's still a potential allocator mismatch lurking, but apart for that, if that's something we want and the specification is a little more fleshed out, I'm fine.

Comment thread tests/network/remote/remotes.c Outdated
Comment thread tests/network/remote/remotes.c Outdated
@ethomson
Copy link
Copy Markdown
Member

I'm happy with this git_buf approach. Callers can set it if they wish using git_buf_set, at which point we do a copy, so we control both the allocator and the free function.

I'm heads-down on the day job though so I'm very scattered, and I'd like to hold off just to make sure that I haven't missed anything before we 🚢 this.

@ethomson
Copy link
Copy Markdown
Member

Sorry, to clarify, hold off for another core contributor to 👍 this in case I'm missing something.

@eaigner eaigner closed this Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants