git-credential-libsecret not prompting to unlock keyring
> Apologies, forgot the crucial details post that log: This turned out to be an error unrelated to git or git-credential-libsecret. Apologies for the noise (and the badly threaded reply earlier). Paul
Re: git-credential-libsecret not prompting to unlock keyring
Apologies, forgot the crucial details post that log: $ git --version git version 2.19.0 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.1 LTS Release:18.04 Codename: bionic
git-credential-libsecret not prompting to unlock keyring
Hi, For some reason today, after an apt update, my combination of GNOME keyring and git-credential-libsecret stopped working. Stopped working in so far as I am no longer prompted by GNOME keyring to unlock my keyring, instead I get prompted for the password that git is looking for. Trace output below; would appreciate any pointers. Many thanks == $ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git push 13:38:59.324799 git.c:415 trace: built-in: git push 13:38:59.325070 run-command.c:637 trace: run_command: GIT_DIR=.git git-remote-https origin https://github.com/myitcv/go-modules-by-example * Couldn't find host github.com in the .netrc file; using defaults * Trying 192.30.253.113... * TCP_NODELAY set * Connected to github.com (192.30.253.113) port 443 (#0) * found 133 certificates in /etc/ssl/certs/ca-certificates.crt * found 399 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256 *server certificate verification OK *server certificate status verification SKIPPED *common name: github.com (matched) *server certificate expiration date OK *server certificate activation date OK *certificate public key: RSA *certificate version: #3 *subject: businessCategory=Private Organization,jurisdictionOfIncorporationCountryName=US,jurisdictionOfIncorporationStateOrProvinceName=Delaware,serialNumber=5157550,C=US,ST=California,L=San Francisco,O=GitHub\, Inc.,CN=github.com *start date: Tue, 08 May 2018 00:00:00 GMT *expire date: Wed, 03 Jun 2020 12:00:00 GMT *issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 Extended Validation Server CA *compression: NULL * ALPN, server accepted to use http/1.1 > GET /myitcv/go-modules-by-example/info/refs?service=git-receive-pack HTTP/1.1 Host: github.com User-Agent: git/2.19.0 Accept: */* Accept-Encoding: deflate, gzip Accept-Language: en-GB, *;q=0.9 Pragma: no-cache < HTTP/1.1 401 Authorization Required < Server: GitHub Babel 2.0 < Content-Type: text/plain < Content-Length: 60 < WWW-Authenticate: Basic realm="GitHub" < X-GitHub-Request-Id: EF1E:073A:6C8091:C2DB67:5B9908E8 < X-Frame-Options: DENY < * Connection #0 to host github.com left intact 13:39:05.084588 run-command.c:637 trace: run_command: '/home/myitcv/dev/git/contrib/credential/libsecret/git-credential-libsecret get' Password for 'https://myi...@github.com':
Re: Change in behaviour in git fetch between 2.18.0 and 2.18.0.547.g1d89318c48
> I think this is the bug from: > > https://public-inbox.org/git/20180729121900.ga16...@sigill.intra.peff.net/ > > The fix is in e2842b39f4 (fetch-pack: unify ref in and out param, > 2018-08-01), and is currently in the 'next' branch, and marked for > merging to master in the next integration cycle. Thanks for the pointer, sounds like my case exactly. Paul
Change in behaviour in git fetch between 2.18.0 and 2.18.0.547.g1d89318c48
Hi, I've tried to skim through the archive, but I couldn't find anything that describes what I'm seeing. Apologies if that's because I missed something/used the wrong search terms, or this is an intentional change in behaviour. Using 2.18.0.547.g1d89318c48, git fetch behaves differently to 2.18.0. The scenario in which I'm seeing a difference in behaviour is when there are (by virtue of the state of my local git repo and the origin, remote) pending objects, branch updates etc to fetch from the remote. To compare, here is the output of git fetch -v using 2.18.0: POST git-upload-pack (948 bytes) remote: Counting objects: 8961, done remote: Finding sources: 100% (9/9) remote: Total 9 (delta 0), reused 6 (delta 0) Unpacking objects: 100% (9/9), done. >From https://go.googlesource.com/go = [up-to-date]dev.boringcrypto-> origin/dev.boringcrypto = [up-to-date]dev.boringcrypto.go1.10 -> origin/dev.boringcrypto.go1.10 = [up-to-date]dev.boringcrypto.go1.8 -> origin/dev.boringcrypto.go1.8 = [up-to-date]dev.boringcrypto.go1.9 -> origin/dev.boringcrypto.go1.9 = [up-to-date]dev.cc -> origin/dev.cc = [up-to-date]dev.debug -> origin/dev.debug = [up-to-date]dev.garbage -> origin/dev.garbage = [up-to-date]dev.gcfe-> origin/dev.gcfe = [up-to-date]dev.inline -> origin/dev.inline = [up-to-date]dev.power64 -> origin/dev.power64 = [up-to-date]dev.ssa -> origin/dev.ssa = [up-to-date]dev.tls -> origin/dev.tls = [up-to-date]dev.typealias -> origin/dev.typealias 479da24aac..dce644d95b master -> origin/master = [up-to-date]release-branch.go1 -> origin/release-branch.go1 = [up-to-date]release-branch.go1.1-> origin/release-branch.go1.1 = [up-to-date]release-branch.go1.10 -> origin/release-branch.go1.10 = [up-to-date]release-branch.go1.2-> origin/release-branch.go1.2 = [up-to-date]release-branch.go1.3-> origin/release-branch.go1.3 = [up-to-date]release-branch.go1.4-> origin/release-branch.go1.4 = [up-to-date]release-branch.go1.5-> origin/release-branch.go1.5 = [up-to-date]release-branch.go1.6-> origin/release-branch.go1.6 = [up-to-date]release-branch.go1.7-> origin/release-branch.go1.7 = [up-to-date]release-branch.go1.8-> origin/release-branch.go1.8 = [up-to-date]release-branch.go1.9-> origin/release-branch.go1.9 = [up-to-date]release-branch.r57 -> origin/release-branch.r57 = [up-to-date]release-branch.r58 -> origin/release-branch.r58 = [up-to-date]release-branch.r59 -> origin/release-branch.r59 = [up-to-date]release-branch.r60 -> origin/release-branch.r60 Notice the update to origin/master. Here is the output of git fetch -v using 2.18.0.547.g1d89318c48: POST git-upload-pack (964 bytes) remote: Counting objects: 8961, done remote: Finding sources: 100% (9/9) remote: Total 9 (delta 0), reused 6 (delta 0) Unpacking objects: 100% (9/9), done. >From https://go.googlesource.com/go = [up-to-date]dev.boringcrypto-> origin/dev.boringcrypto = [up-to-date]dev.boringcrypto.go1.10 -> origin/dev.boringcrypto.go1.10 = [up-to-date]dev.boringcrypto.go1.8 -> origin/dev.boringcrypto.go1.8 = [up-to-date]dev.boringcrypto.go1.9 -> origin/dev.boringcrypto.go1.9 = [up-to-date]dev.cc -> origin/dev.cc = [up-to-date]dev.debug -> origin/dev.debug = [up-to-date]dev.garbage -> origin/dev.garbage = [up-to-date]dev.gcfe-> origin/dev.gcfe = [up-to-date]dev.inline -> origin/dev.inline = [up-to-date]dev.power64 -> origin/dev.power64 = [up-to-date]dev.ssa -> origin/dev.ssa = [up-to-date]dev.tls -> origin/dev.tls = [up-to-date]dev.typealias -> origin/dev.typealias = [up-to-date]release-branch.go1 -> origin/release-branch.go1 = [up-to-date]release-branch.go1.1-> origin/release-branch.go1.1 = [up-to-date]release-branch.go1.10 -> origin/release-branch.go1.10 = [up-to-date]release-branch.go1.2-> origin/release-branch.go1.2 = [up-to-date]release-branch.go1.3-> origin/release-branch.go1.3 = [up-to-date]release-branch.go1.4-> origin/release-branch.go1.4 = [up-to-date]release-branch.go1.5-> origin/release-branch.go1.5 = [up-to-date]release-branch.go1.6->
Re: [PATCH 3/2] ls-files: only recurse on active submodules
> It looks like it was merged to master. This should be the relevant > commit: 188dce131 (ls-files: use repository object, 2017-06-22). I was just typing a response to my response. Apologies, I was testing locally with the wrong compiled version of git. Confirmed fixed for me in e2d9c4613 at least. Thanks again
Re: [PATCH 3/2] ls-files: only recurse on active submodules
>> Thanks for the quick response. > > Course, let me know if you find anything else! :D Brandon - doesn't look like this change has made it's way into master: https://github.com/git/git/blob/master/builtin/ls-files.c Is there a plan to merge it? Thanks
Re: [PATCH 3/2] ls-files: only recurse on active submodules
>> How can I help diagnose what's going on here? > Welp that's a pretty terrible bug which stems from > missing a check to see if a submodule is initialized, and not explicitly > setting GIT_DIR=.git (theres cases where we don't want this but turns > out we probably should do that here). Let me know if this fixes the > problem: That's certainly fixed the fork explosion. Indeed seems to now work as expected from my perspective... And also answers the question that I was going to ask, namely whether git ls-files --recurse-submodules should work on repos that do not contain any submodules... to which I'd hoped the answer was "yes" (because as I said it was a fatal error in v2.11.x, despite there being some output). The behaviour I'm now seeing appears to affirm that, assuming it's as expected from your perspective! Thanks for the quick response.
