FS#50887 - [pacman] makepkg: less strict Git local clone check for remotes differing only in protocol
Attached to Project:
Pacman
Opened by Alain Kalker (ackalker) - Saturday, 24 September 2016, 20:42 GMT
Last edited by Allan McRae (Allan) - Sunday, 25 September 2016, 00:21 GMT
Opened by Alain Kalker (ackalker) - Saturday, 24 September 2016, 20:42 GMT
Last edited by Allan McRae (Allan) - Sunday, 25 September 2016, 00:21 GMT
|
Details
Description:
I'm a fan of the (undocumented?) feature of symlinking checked-out Git repositories into my $SRCDEST and building AUR packages referring to the upstream version of these repositories. For Github repositories I usually use the `hub` tool's shorthand: `hub clone <user>/<repo>`, which defaults to checking out repositories using the `git:` protocol. A problem which I have ran into quite a few time: when I try to build a package whose PKGBUILD `source` array specifies a `git+https:` URL but my checked-out repo has an `origin` remote specifying `git:` protocol. In this case, `makepkg` complains with an error like: "/path/to/repo is not a clone of https://github.com/user/repo.git" and refuses to build the package. I know that I can change `hub`'s use of protocol for cloning, but it is a global setting which I would have to set before and then delete after cloning any repository with the stated problem. Of couse I could also do a `git remote set-url` on the checked-out repo, but I'm not confident that this will not interfere with yet other tools which I use to fork and push repos to Github. Please consider making `makepkg`'s local clone check less strickt when the remote of the checked-out repo and that specified by PKGBUILD differ only in protocol. Thank you. Additional info: * package version(s) pacman 5.0.1-4 * config and/or log files etc. Steps to reproduce: |
This task depends upon
Granted it is unlikely the prepare() function will apply commits from some private ref (like github's /refs/pull/*/head) which is the only practical effect I can think of.
2) Git repositories served over git://somepath vs. https://somepath can *technically* be completely different repos, even though it is highly unlikely they will be anything other than the same set of repos served over the same path and different protocols as a convenience. But that isn't technically correct...
I think a better solution is for you to embrace git's insteadOf/pushInsteadOf config options. e.g. I use the following for the github domain, to ensure that no matter which protocol I set as the remote url, fetching always occurs over HTTPS and pushes over SSH. This has a few advantages, including the fact that smart HTTPS is slightly more efficient than git:// and git:// should only ever be used in preference over dumb HTTPS:
```
[url "https://github.com/"]
insteadOf = git://github.com/
[url "git@github.com:"]
pushInsteadOf = git://github.com/
pushInsteadOf = https://github.com/
```
Note: Some PKGBUILDs clone over HTTPS, some over git:// so there is really no one solution fits all for your own `hub clone` usage, you will almost certainly have to change some/many of them at some point anyway.