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
Task Type Feature Request
Category Packages: Core
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

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&quot; 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

Comment by Allan McRae (Allan) - Sunday, 25 September 2016, 00:20 GMT
Or edit the PKGBUILD to match.
Comment by Alain Kalker (ackalker) - Sunday, 25 September 2016, 01:47 GMT
Sure, but then I will have to merge my change back in whenever there's an updated PKGBUILD in the AUR or official repos ;)
Comment by Daniel M. Capella (polyzen) - Thursday, 10 November 2016, 02:03 GMT
Alain, Hub can use the HTTPS protocol <https://github.com/github/hub/blob/master/share/man/man1/hub.1.ronn#L98>.
Comment by Eli Schwartz (eschwartz) - Tuesday, 26 September 2017, 17:40 GMT
1) This "undocumented feature" can have unexpected effects since the default `git clone` refspec for fetching is +refs/heads/*:refs/remotes/origin/* whereas makepkg uses `git clone --mirror` which configures the repository to fetch +refs/*:refs/*
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.

Loading...